Re: [Python-Dev] tp_finalize vs tp_del sematics
Hi Armin, On 04.09.2015 02:29, Armin Rigo wrote: Hi Valentine, On Thu, Sep 3, 2015 at 9:15 PM, Valentine Sinitsyn wrote: That does not make it ok to have del called several time, does it? That's a tricky question. If the Python documentation now says something like ``the __del__ method is never called more than once on the same instance'' without acknowledging this corner case, then it could be regarded as documentation bug. I didn't check, though. But feel free to open an issue and mention everything I said above, if you want to. I've checked the places I remembered, but didn't find any guarantees for __del__ to be called exactly once in general. Looks like it was only important to ensure safe finalization. Looks a bit inconsistent though so it's probably appropriate to file the report. Valentine ___ 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] Summary of Python tracker Issues
ACTIVITY SUMMARY (2015-08-28 - 2015-09-04) 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: open5057 (+15) closed 31704 (+33) total 36761 (+48) Open issues with patches: 2257 Issues opened (28) == #24954: No way to generate or parse timezone as produced by datetime.i http://bugs.python.org/issue24954 opened by gvanrossum #24955: webbrowser broken on Mac OS X when using the BROWSER variable http://bugs.python.org/issue24955 opened by sconseil #24956: Default value for an argument that is not in the choices list http://bugs.python.org/issue24956 opened by Sworddragon #24957: python3 -mpdb gets stuck in an unexitable infinite prompt loop http://bugs.python.org/issue24957 opened by shlomif #24959: unittest swallows part of stack trace when raising AssertionEr http://bugs.python.org/issue24959 opened by chris.jerdonek #24960: Can't use pip or easy_install with embeddable zip file. http://bugs.python.org/issue24960 opened by Oleg N #24964: Add tunnel CONNECT response headers to httplib / http.client http://bugs.python.org/issue24964 opened by Thomas #24965: Implement PEP 498: Literal String Formatting http://bugs.python.org/issue24965 opened by eric.smith #24966: shutil.get_terminal_size() throws ValueError if stdout is deta http://bugs.python.org/issue24966 opened by rsc1975 #24969: functools.lru_cache: a way to set decorator arguments at runti http://bugs.python.org/issue24969 opened by Marek Otahal #24970: Make distutils.Command an ABC http://bugs.python.org/issue24970 opened by Antony.Lee #24972: IDLE: revisit text highlighting for inactive windows on win32 http://bugs.python.org/issue24972 opened by markroseman #24973: CFLAGS for Visual Studio http://bugs.python.org/issue24973 opened by christopher.hogan #24977: shutil copy to non-existant directory http://bugs.python.org/issue24977 opened by TheOrangeOne #24978: Contributing to Python 2x and 3x Documentation. Translation to http://bugs.python.org/issue24978 opened by overr1de #24980: Allow for providing 'on_new_thread' callback to 'concurrent.fu http://bugs.python.org/issue24980 opened by harlowja #24981: Add a test which uses the ast module to compile the stdlib http://bugs.python.org/issue24981 opened by brett.cannon #24982: shutil.make_archive doesn't archive empty directories http://bugs.python.org/issue24982 opened by eugenek #24984: document AF_BLUETOOTH socket address formats http://bugs.python.org/issue24984 opened by Tim.Tisdall #24985: Python install test fails - OpenSSL - "dh key too small" http://bugs.python.org/issue24985 opened by nagle #24988: IDLE: debugger context menus not working on Mac http://bugs.python.org/issue24988 opened by markroseman #24990: Foreign language support in turtle module http://bugs.python.org/issue24990 opened by Al.Sweigart #24991: Define instance mutability explicitly on type objects http://bugs.python.org/issue24991 opened by ncoghlan #24995: better exception message when an unsupported object is passed http://bugs.python.org/issue24995 opened by yselivanov #24996: IDLE: debugger local/global vars should not be editable http://bugs.python.org/issue24996 opened by markroseman #24997: mock.call_args compares as equal and not equal http://bugs.python.org/issue24997 opened by akaptur #24999: Segfault in test_re.test_sre_character_class_literals() when P http://bugs.python.org/issue24999 opened by haypo #25000: _mock_call does not properly grab args and kwargs http://bugs.python.org/issue25000 opened by paetling Most recent 15 issues with no replies (15) == #24997: mock.call_args compares as equal and not equal http://bugs.python.org/issue24997 #24985: Python install test fails - OpenSSL - "dh key too small" http://bugs.python.org/issue24985 #24972: IDLE: revisit text highlighting for inactive windows on win32 http://bugs.python.org/issue24972 #24970: Make distutils.Command an ABC http://bugs.python.org/issue24970 #24960: Can't use pip or easy_install with embeddable zip file. http://bugs.python.org/issue24960 #24954: No way to generate or parse timezone as produced by datetime.i http://bugs.python.org/issue24954 #24942: Remove domain from ipaddress.reverse_pointer property and add http://bugs.python.org/issue24942 #24940: RotatingFileHandler uses tell in non-binary mode to determine http://bugs.python.org/issue24940 #24936: Idle: handle 'raise' properly when running with subprocess (2. http://bugs.python.org/issue24936 #24925: Allow doctest to find line number of __test__ strings if forma http://bugs.python.org/issue24925 #24924: _posixsubprocess.c: sysconf() might not be async-signal-safe http://bugs.python.org/issue24924 #24923: Append system paths in setup.py instead of prepending http://bugs.python.org/issue24923 #24922: assertWarnsRegex doesn'
[Python-Dev] Should we use getentropy() for os.urandom()?
Hi, I followed discussions on the new systems getrandom() on Linux and getentropy() on OpenBSD. I wanted to use them in Python to avoid the need of a file descriptor to read /dev/urandom. Linux getrandom() is also more secure than /dev/urandom because it blocks until /dev/urandom is feeded with enough entropy. getentropy() and getrandom() are now used in Python 2.7.10, Python 3.4 and newer. Today, an issue was reported on Solaris because os.urandom() is much slower with Python 2.7.10: https://bugs.python.org/issue25003 It looks like Solaris has getrandom() and getentropy(), and getentropy() is slow. Now I'm not sure that I understood the purpose of getentropy() even on OpenBSD. Should it be used to feed a PRNG in user-space, or can it be used as a PRNG? http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/getentropy.2?query=getentropy&sec=2 If getentropy() must only be used to feed a PRNG (which only use a few bytes), we should remove the code using getentropy() (but getrandom() should be kept). Note: I didn't know that other operating systems supported getrandom() and getentropy()! The feature looks recent in Solaris: " Solaris 11.3 adds two new system calls, getrandom(2) and getentropy(2), for getting random bit streams or raw entropy." https://blogs.oracle.com/darren/entry/solaris_new_system_calls_getentropy (article published at July, 2015) Note2: There is an open discussion proposing to "Use arc4random under OpenBSD for os.urandom() if /dev/urandom is not present" https://bugs.python.org/issue22542 getentropy() issue in Python (closed): https://bugs.python.org/issue22585 getrandom() issue in Python (closed): https://bugs.python.org/issue22181 Victor ___ 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] Should we use getentropy() for os.urandom()?
I'm no expert, but from the bug report and the man page you quoted it does sound like getentropy() should only be used to seed a PRNG. It also sounds like reading /dev/[u]random should be considered a PRNG. For evidence, the man page on OS X says: "The random device produces uniformly distributed random byte values of potentially high quality." It goes on to describe the difference between the two on Linux (where urandom produces lower quality when it runs out of entropy while random apparently blocks). It does sound like we should not call getentropy() except to get a good seed for our own PRNG. On Fri, Sep 4, 2015 at 3:45 PM, haypo s wrote: > Hi, > > I followed discussions on the new systems getrandom() on Linux and > getentropy() on OpenBSD. I wanted to use them in Python to avoid the > need of a file descriptor to read /dev/urandom. > > Linux getrandom() is also more secure than /dev/urandom because it > blocks until /dev/urandom is feeded with enough entropy. > > getentropy() and getrandom() are now used in Python 2.7.10, Python 3.4 > and newer. > > Today, an issue was reported on Solaris because os.urandom() is much > slower with Python 2.7.10: > https://bugs.python.org/issue25003 > > It looks like Solaris has getrandom() and getentropy(), and > getentropy() is slow. > > Now I'm not sure that I understood the purpose of getentropy() even on > OpenBSD. Should it be used to feed a PRNG in user-space, or can it be > used as a PRNG? > > > http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/getentropy.2?query=getentropy&sec=2 > > If getentropy() must only be used to feed a PRNG (which only use a few > bytes), we should remove the code using getentropy() (but getrandom() > should be kept). > > Note: I didn't know that other operating systems supported getrandom() > and getentropy()! The feature looks recent in Solaris: > " Solaris 11.3 adds two new system calls, getrandom(2) and > getentropy(2), for getting random bit streams or raw entropy." > https://blogs.oracle.com/darren/entry/solaris_new_system_calls_getentropy > (article published at July, 2015) > > Note2: There is an open discussion proposing to "Use arc4random under > OpenBSD for os.urandom() if /dev/urandom is not present" > https://bugs.python.org/issue22542 > > getentropy() issue in Python (closed): > https://bugs.python.org/issue22585 > > getrandom() issue in Python (closed): > https://bugs.python.org/issue22181 > > Victor > ___ > 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/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ 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] Should we use getentropy() for os.urandom()?
On September 4, 2015 at 7:08:36 PM, Guido van Rossum (gu...@python.org) wrote: > I'm no expert, but from the bug report and the man page you quoted it does > sound like getentropy() should only be used to seed a PRNG. It also sounds > like reading /dev/[u]random should be considered a PRNG. For evidence, the > man page on OS X says: "The random device produces uniformly distributed > random byte values of potentially high quality." It goes on to describe the > difference between the two on Linux (where urandom produces lower quality > when it runs out of entropy while random apparently blocks). It does sound > like we should not call getentropy() except to get a good seed for our own > PRNG. I don't recall the difference between getentropy and getrandom but /dev/(u)random are basically the exact same except /dev/random tries to gues how "random" it’s numbers are. The manpage for /dev/(u)random is basically wrong. (See http://www.2uo.de/myths-about-urandom/ and http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/). Someone who remembers what getentropy implements would have to chime in on whether we should use it or not, but getrandom is basically a better form of /dev/urandom. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ 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] PEP 498: Literal String Interpolation is ready for pronouncement
I've made a number of small changes to PEP 498. I don't think any of the changes I've made in the last week are substantive. Mostly I've clarified how it works and removing some limitations. The only meaningful change is that expressions are now surrounded by parens before they're evaluated. This allows for newlines inside of the expressions to be ignored. I think it's now ready for Guido to pronounce on it. The code in issue 24965 is slightly out of date, in that it has some limitations that are no longer mentioned in the PEP and doesn't enclose the expression in parens before evaluation. If the PEP is accepted, I'll fix that and update the issue. -- 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] PEP 498: Literal String Interpolation is ready for pronouncement
On Sep 04 2015, "Eric V. Smith" wrote: > I've made a number of small changes to PEP 498. I don't think any of the > changes I've made in the last week are substantive. Mostly I've > clarified how it works and removing some limitations. The only > meaningful change is that expressions are now surrounded by parens > before they're evaluated. This allows for newlines inside of the > expressions to be ignored. > > I think it's now ready for Guido to pronounce on it. I just wanted to say that I think this is fantastic work. If the PEP gets accepted, I expect that in my code f-strings will replace the other interpolation mechanism in almost all cases. 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
[Python-Dev] PEP 501 Shell Command Examples
Hi Nick,
You are giving
runcommand(sh(i"cat {filename}"))
as an example that avoids injection attacks. While this is true, I think
this is still a terrible anti-pattern[1] that should not be entombed in
a PEP as a positive example.
Could you consider removing it?
(It doubly wastes resources by pointlessly calling a shell, and then by
parsing & quoting the argument only for the shell to do the same in
reverse).
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] PEP 498: Literal String Interpolation is ready for pronouncement
On Fri, Sep 4, 2015 at 6:45 PM, Eric V. Smith wrote: > I've made a number of small changes to PEP 498. I don't think any of the > changes I've made in the last week are substantive. Mostly I've > clarified how it works and removing some limitations. The only > meaningful change is that expressions are now surrounded by parens > before they're evaluated. This allows for newlines inside of the > expressions to be ignored. > > I think it's now ready for Guido to pronounce on it. > And I'm ready to accept it. I'll wait until Tuesday night (Monday's a holiday in the US) in case anything unforeseen comes up, but this is really the Last Call for this PEP. > The code in issue 24965 is slightly out of date, in that it has some > limitations that are no longer mentioned in the PEP and doesn't enclose > the expression in parens before evaluation. If the PEP is accepted, I'll > fix that and update the issue. No worries. (The parens thing was something I suggested to Eric this afternoon. :-) I'll say a few words about PEPs 501 and 502, but I'll start separate threads. -- --Guido van Rossum (python.org/~guido) ___ 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] Critique of PEP 501 (General purpose string interpolation)
I think it's too much effort for too little gain.
The motivation feels very weak; surely writing
os.system("echo " + message_from_user)
is just as easy (as is the %s spelling), so the security issue can hardly
be blamed on PEP 498.
I also don't think that the current way to address such security issues is
a big deal:
- The subprocess module is complex for other reasons, and a simpler wrapper
could easily be made;
- Database wrappers have forever included their own solution for safely
quoting query parameters, and people who still don't use that are not
likely to care about i-strings either.
- Logging: again, it's hard to beat the existing solution, which mostly
comes down to using %r instead of %s for any user-supplied or otherwise
unverified data.
- HTML quoting is an art and I'm skeptical that the proposal will even work
for that use case.
--
--Guido van Rossum (python.org/~guido)
___
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] Critique of PEP 502 (String Interpolation Redux)
The text of the PEP has too much on motivation and rationale: maybe that would be suitable for an informative PEP. The proposal itself is under-specified. But the real weakness cannot be fixed by improving the text: it is in the key characteristic of the proposal, which wants to have its cake and eat it, too. This is initially likable: to recipients who don't know about e-strings they behave just like regular strings; but recipients who *do* know about them can extract the template and the values to be interpolated and use these to build an alternative string, e.g. to be used as a translation. However, in order to fulfill the former requirement, the type must inherit from str (it's one of those built-in types for which duck typing doesn't always work). And at the same time this is a real problem, because it's too easy to lose the e-string. For example, any function that operates on strings will operate on e-strings, but the result will in general be a plain str instead of an e-string, which can be confusing for functions that want the e-string. But *not* inheriting from str causes the reverse problem. IOW, e-strings don't make a good alternative for f-strings -- they would have to be added as a second string type. And the proliferation of similar but different template string types cannot make anyone happy. -- --Guido van Rossum (python.org/~guido) ___ 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
