Re: [Python-Dev] PEPs shouldn't be considered docs
On Oct 11, 2013, at 07:24 AM, Ned Batchelder wrote:>I'd like to suggest that we not consider PEPs to be documentation. Absolutely +1. That was never the intention behind PEPs. -Barry ___ Python-Dev mailing list [email protected] https://mail.pyth
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On Oct 11, 2013, at 09:24 AM, Antoine Pitrou wrote:>I don't think that this contextlib.ignore() thing has been discussed a>lot.>>Ezio was -1 on the tracker, and Eric Smith was -0. I'd like to add my>-1 too. This is a useless addition (the traditional idiom is perfectly>obvious) and makes rea
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On Oct 11, 2013, at 06:27 PM, Georg Brandl wrote:>Maybe to fit in with other verb-like APIs used as context managers:>it's open() not opened(). open() predates context managers, but maybe we need a new convention. with ignore(FileNotFoundError): vs with ignored(FileNotFoundError): To me any
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On Oct 11, 2013, at 01:19 PM, Eric V. Smith wrote:>But, to continue to paint the shed, shouldn't it be "ignoring", to match>"closing"? Maybe so. -Barry ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On Oct 11, 2013, at 08:32 PM, Serhiy Storchaka wrote:>I am -1 too. But I want to hear more about interact with ExitStack (note that>ExitStack itself is not widely used in the stdlib). Yet. :) -Barry ___ Python-Dev mailing list [email protected]
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On Oct 12, 2013, at 09:06 AM, Nick Coghlan wrote:>I'm not too fussy about the name (clearly). We originally picked ignored(),>Raymond asked if he could change it to ignore() (and I said yes), Just as a point of order, it would be good to capture such side-channel discussions in the relevant iss
Re: [Python-Dev] PEPs shouldn't be considered docs
On Oct 12, 2013, at 11:19 AM, Brett Cannon wrote:>Actually thanks should go to Barry who rewrote the language ref docs for>import. I can actually say it was fun due to all the great work on importlib. :) -Barry ___ Python-Dev mailing list Python-Dev@
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On Oct 12, 2013, at 03:27 PM, Raymond Hettinger wrote:>The module maintainer (Nick) approved the name change from his original>preference for ignored(). That should had been the end of it. As a general plea, please be sure to record the rationale and decisions in the appropriate place, such as
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On Oct 15, 2013, at 11:52 AM, R. David Murray wrote:>I think 'trap' would be much clearer. What about making the context>manager provide the trapped exception, in a fashion similar to>what assertRaises does? Even if that was almost never used in practice,>the fact that the CM provides only *
Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().
On Oct 16, 2013, at 08:31 AM, Eric Snow wrote:>When a module's maintainer makes a decision on a relatively insignificant>addition to the module, I'd expect little resistance or even comment (the>original commit was months ago). That's why I'm surprised by the reaction>to this change. It just
[Python-Dev] On suppress()'s trail blazing (was Re: cpython: Rename contextlib.ignored() to contextlib.ignore())
On Oct 18, 2013, at 01:26 AM, Nick Coghlan wrote:>By contrast, suppress() and redirect_stdout() are the *first* general>purpose context managers added to contextlib since its incarnation in>Python 2.5 (although there have been many various domain specific>context manager additions elsewhere in
Re: [Python-Dev] On suppress()'s trail blazing (was Re: cpython: Rename contextlib.ignored() to contextlib.ignore())
On Oct 17, 2013, at 08:40 PM, Xavier Morel wrote:>I think there's already a significant split between context managers>which handle the lifecycle of a local resource (file, transaction) and>those which purport to locally alter global-ish state (cwd,>decimal.localcontext, logging.captureWarning
Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview
On Jun 07, 2016, at 01:28 PM, Ethan Furman wrote:>* Add ``bytes.iterbytes``, ``bytearray.iterbytes`` and> ``memoryview.iterbytes`` alternative iterators +1 but I want to go just a little farther. We can't change bytes.__getitem__ but we can add another method that returns single byte objects
Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview
On Jun 07, 2016, at 09:40 PM, Brett Cannon wrote:>On Tue, 7 Jun 2016 at 14:38 Paul Sokolovsky wrote:>> What's wrong with b[i:i+1] ?>It always succeeds while indexing can trigger an IndexError. Right. You want a method with the semantics of __getitem__() but that returns the desired type. -B
Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview
On Jun 08, 2016, at 02:01 AM, Martin Panter wrote:>Bytes.byte() is a great idea. But what’s the point or use case of>bytearray.byte(), a mutable array of one pre-defined byte? I like Bytes.byte() too. I would guess you'd want the same method on bytearray for duck typing APIs. -Barry _
Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
On Jun 09, 2016, at 03:22 PM, Larry Hastings wrote:>On 06/09/2016 08:52 AM, Guido van Rossum wrote:>> That leaves direct calls to os.urandom(). I don't think this should> block >> either. >>Then it's you and me against the rest of the world ;-) FWIW, I agree with you and Guido. I'm also n
Re: [Python-Dev] Smoothing the transition from Python 2 to 3
On Jun 09, 2016, at 05:35 PM, Neil Schemenauer wrote:>Amber Brown claimed that she spent 60ドルk of her time porting Twisted to Python>3. I think there is lots of room to make our porting tools better. Amber gave a presentation at the language summit and a Pycon talk. The latter video is up on Y
Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview
On Jun 07, 2016, at 01:28 PM, Ethan Furman wrote:>Deprecation of current "zero-initialised sequence" behaviour>>>Currently, the ``bytes`` and ``bytearray`` constructors accept an integer>argument and interpret it as meaning to create
Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
On Jun 10, 2016, at 12:05 PM, David Mertz wrote:>OK. My understanding is that Guido ruled out introducing an os.getrandom()>API in 3.5.2. But would you be happy if that interface is added to 3.6? I would.>It feels to me like the correct spelling in 3.6 should probably be>secrets.getrandom(
Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
On Jun 15, 2016, at 01:01 PM, Nick Coghlan wrote:>No, this is a bad idea. Asking novice developers to make security>decisions they're not yet qualified to make when it's genuinely>possible for us to do the right thing by default is the antithesis of>good security API design, and os.urandom() *
Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
On Jun 15, 2016, at 11:52 PM, Larry Hastings wrote:>Well, 3.5.2 hasn't happened yet. So if you see it as still being broken,>please speak up now. In discussion with other Ubuntu developers, several salient points were raised. The documentation for os.urandom() in 3.5.2rc1 doesn't make sense:
Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
On Jun 16, 2016, at 07:26 PM, Robert Collins wrote:>Which is a contract change. Someone testing in E.g. a chroot could have a>different device on /dev/urandom, and now they will need to intercept>syscalls for the same effect. Personally I think this is fine, but assuming>i see Barry's point co
Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
On Jun 16, 2016, at 12:53 AM, Nathaniel Smith wrote:>> We have introduced churn. Predicting a future SO question such as "Can>> os.urandom() block on Linux?" the answer is "No in Python 3.4 and earlier,>> yes possibly in Python 3.5.0 and 3.5.1, no in Python 3.5.2 and the rest of>> the 3.5.x s
Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
On Jun 16, 2016, at 12:36 AM, Nathaniel Smith wrote:>Basically this is a question of whether we should make an (unlikely) error>totally invisible to the user, and "errors should never pass silently" is>right there in the Zen of Python :-). I'd phrase it differently though. To me, it comes dow
Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
On Jun 16, 2016, at 01:40 AM, Larry Hastings wrote:>As Robert Collins points out, this does change the behavior ever-so-slightly>from 3.4; Ah yes, I misunderstood Robert's point.>if urandom is initialized, and the kernel has the getrandom system call,>getrandom() will give us the bytes we as
[Python-Dev] Our responsibilities (was Re: BDFL ruling request: should we block forever waiting for high-quality random bits?)
On Jun 16, 2016, at 06:04 AM, Donald Stufft wrote:>Regardless of what we document it as, people are going to use os.urandom for>cryptographic purposes because for everyone who doesn’t keep up on exactly>what modules are being added to Python who has any idea about cryptography at>all is going
Re: [Python-Dev] Our responsibilities (was Re: BDFL ruling request: should we block forever waiting for high-quality random bits?)
On Jun 16, 2016, at 07:34 AM, Donald Stufft wrote:>Well, I don’t think that for os.urandom someone using it for security is>running "counter to it’s original intent", given that in general urandom’s>purpose is for cryptographic random. Someone *may* be using it for something>other than that, b
Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
On Jun 16, 2016, at 09:51 AM, Random832 wrote: >On Thu, Jun 16, 2016, at 04:03, Barry Warsaw wrote: >> *If* we can guarantee that os.urandom() will never block or raise an >> exception when only poor entropy is available, then it may be indeed >> indistinguishably backward c
Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
On Jun 16, 2016, at 01:01 PM, David Mertz wrote:>It seems to me that backporting 'secrets' and putting it on Warehouse would>be a lot more productive than complaining about 3.5.2 reverting to (almost)>the behavior of 2.3-3.4. Very wise suggestion indeed. We have all kinds of stdlib modules ba
Re: [Python-Dev] security SIG? (was: Discussion overload)
On Jun 18, 2016, at 03:06 AM, Brett Cannon wrote:>Do we need a security SIG? E.g. would people like Christian and Cory like>to have a separate place to talk about the ssl stuff brought up at the>language summit? The only thing I'd be worried about is people thinking that the sig is the place t
Re: [Python-Dev] security SIG? (was: Discussion overload)
On Jun 18, 2016, at 03:30 PM, Cory Benfield wrote:>Unless that SIG is empowered to take action It wouldn't be, but there *is* a private security mailing list that is. Christian was on it, and I'm sad that he got burned out. If you are willing and able to help out there, please contact security
Re: [Python-Dev] Request for CPython 3.5.3 release
On Jul 03, 2016, at 01:17 AM, Ludovic Gasc wrote:>If 3.5.2.1 or 3.5.3 are impossible to release before december, what are the>alternative solutions for AsyncIO users ?>1. Use 3.5.1 and hope that Linux distributions won't use 3.5.2 ? Matthias just uploaded a 3.5.2-2 to Debian unstable, which wi
Re: [Python-Dev] Breaking up the stdlib (Was: release cadence)
On Jul 05, 2016, at 11:19 AM, Victor Stinner wrote:>pip supports a requirements.txt file which is a nice may to declare>dependency. You can:>>* specify the minimum library version>* make some library specific to some operation systems>* skip dependencies on some Python versions -- very helpf
Re: [Python-Dev] release cadence
On Jul 03, 2016, at 04:21 PM, Steve Dower wrote:>A rough count of how I'd break up the current 3.5 Lib folder (which I>happened to have handy) suggests no more than 50 repos. A concern with a highly split stdlib is local testing. I'm not worried about pull request testing, or after-the-fact bu
Re: [Python-Dev] release cadence (was: Request for CPython 3.5.3 release)
On Jul 04, 2016, at 10:31 AM, Nick Coghlan wrote:>While we liked the "consistent calendar cadence that is some multiple>of 6 months" idea, several of us thought 12 months was way too short>as it makes for too many entries in third party support matrices. 18 months for a major release cadence s
Re: [Python-Dev] release cadence
On Jul 05, 2016, at 10:38 AM, Steve Dower wrote:>My hope is that it would be essentially a "pip freeze"/"pip install -r ...">(or equivalent with whatever tool is used/created for managing the>stdlib). Perhaps using VCS URIs rather than version numbers?>>That is, the test run would dump a list
Re: [Python-Dev] release cadence (was: Request for CPython 3.5.3 release)
On Jul 06, 2016, at 10:02 AM, Nick Coghlan wrote: >On 6 July 2016 at 03:44, Barry Warsaw wrote: > >> Projecting ahead, it probably means 3.7 in mid-2018, which is after the >> Ubuntu 18.04 LTS release, so we'll only do one major transition before the >> next LTS. Fr
Re: [Python-Dev] release cadence (was: Request for CPython 3.5.3 release)
On Jul 06, 2016, at 10:55 AM, Nick Coghlan wrote:>However, if we did decide we wanted to take minimising "time to>redistribution" for at least Ubuntu & Fedora into account, then the>two main points to consider would be:>>- starting the upstream beta phase before the first downstream alpha fre
Re: [Python-Dev] Making stdlib modules optional for distributions (Was: Breaking up the stdlib (Was: release cadence))
On Jul 07, 2016, at 08:12 AM, Eric V. Smith wrote:>One thing to keep in mind if we do this is how it interacts with the -S>command line option to not include site-packages in sys.path. I currently use>-S to basically mean "give my python as it was distributed, and don't include>anything that w
[Python-Dev] Fun with ExitStack
I was trying to debug a problem in some work code and I ran into some interesting oddities with contextlib.ExitStack and other context managers in Python 3.5. This program creates a temporary directory, and I wanted to give it a --keep flag to not automatically delete the tempdir at program exit.
Re: [Python-Dev] Issues in Python TLS
On Aug 13, 2016, at 04:14 PM, Benjamin Peterson wrote:>Correctness of TLS certificate verification is known to depend deeply on>distribution. Python began to verify certificates by default only in in>version 2.7.9. Many OS distributions (in particular, Ubuntu) did not>enable verification for t
Re: [Python-Dev] Supported versions of OpenSSL
On Aug 29, 2016, at 12:33 PM, Cory Benfield wrote:>Can someone explain to me why this is a use-case we care about? I do think it would be nice to be able to compile newer versions of Python on stock LTS releases, especially for people developing software that they want to support on a wide-range
Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered
On Sep 09, 2016, at 01:08 PM, Elvis Pranskevichus wrote:>Are there any downsides to explicitly specifying that all dicts are ordered? >People will inevitably start relying on this behaviour, and this will >essentially become the *de-facto* spec, so alternative Python implementations >will hav
Re: [Python-Dev] Update to PEP 1 re: content type
On Oct 13, 2016, at 01:32 PM, Guido van Rossum wrote:>Confirming, +1 from me. Barry, Nick? You two are the most active>authors of PEP 1. +1 for text/x-rst being the preferred. We'd need some time to make it the default, but I'm generally in favor of that happening. Is anybody actively working
Re: [Python-Dev] Update to PEP 1 re: content type
On Oct 13, 2016, at 05:31 PM, Terry Reedy wrote:>The major issue is making knowledge of rst and sphinx a requirement for>submitting a PEP. I suggest making sure that PEP 1 exemplifies the preferred>usage of rst in PEPs and then suggesting using it as model. https://github.com/python/peps/pull
Re: [Python-Dev] [Python-ideas] Show more info when `python -vV`
On Oct 17, 2016, at 05:01 PM, Nick Coghlan wrote:>* Inada-san would like to enable "python -VV" to print the full REPL>header for improved debugging information>* we don't want to mess with "-V" because external scripts may be>relying on it (e.g. to figure out filenames)>* "python -VV" is alr
Re: [Python-Dev] Someons's put a "Python 2.8" on GitHub
On Dec 10, 2016, at 07:09 PM, Steven D'Aprano wrote:>I seem to recall that when we discussed the future of Python 2.x, and the>decision that 2.7 would be the final version and there would be no 2.8, we>reached a consensus that if anyone did backport Python 3 features to a Python>2 fork, they s
Re: [Python-Dev] Deprecate `from __future__ import unicode_literals`?
On Dec 16, 2016, at 01:07 PM, Ethan Furman wrote:>On 12/16/2016 11:24 AM, Guido van Rossum wrote:>>> I am beginning to think that `from __future__ import unicode_literals` does>> more harm than good. I don't recall exactly why we introduced it, but with>> the restoration of u"" literals in
Re: [Python-Dev] Merry Christmas to me, and Python users everywhere
On Dec 27, 2016, at 01:34 PM, Glenn Linderman wrote:>Thanks for this extra information, Ethan. That points at Gmail pretty>conclusively as the source of the reduction in number of messages. Since it>has long been known that Gmail suppresses CC or BCC to self, it is likely>that suppressing dupl
Re: [Python-Dev] Imports with underscores
On Jan 09, 2017, at 11:42 AM, Steve Holden wrote:>So I thought it would be useful to get input from current devs about the>value of this practice, since to me it seems somewhat anti-pythonic. What>advantages does it confer? It just means you can't accidentally import it with a from-import-* si
Re: [Python-Dev] Imports with underscores
On Jan 09, 2017, at 06:23 PM, André Malo wrote:>- __all__ again: it's tedious and error-prone to maintain. Only if you use the wrong tools http://public.readthedocs.io/en/latest/ http://bugs.python.org/issue26632 Cheers, -Barry ___ Python-Dev mailin
Re: [Python-Dev] re performance
On Jan 28, 2017, at 03:43 PM, Nick Coghlan wrote:>I still think it could be a good candidate for a first "bundled">module, where we don't migrate it fully into the CPython development>process, but *do* officially bless it and provide it by default in the>form of a bundled wheel file (similar t
Re: [Python-Dev] re performance
On Jan 30, 2017, at 12:38 PM, Nick Coghlan wrote:>I think there are 3 main candidates that could fit that bill:>>- requests>- setuptools>- regex Actually, I think pkg_resources would make an excellent candidate. The setuptools crew is working on a branch that would allow for setuptools and
Re: [Python-Dev] modules people want installed automatically (was: Re: re performance)
On Jan 30, 2017, at 06:14 PM, Brett Cannon wrote:>What functionality are you after here from pkg_resources? If it's the>reading of data files then you will get that in the stdlib through>importlib as soon as I'm not working on getting our workflow to work>through GitHub's web UI (which obvious
Re: [Python-Dev] Py 3.6 on Ubuntu Zesty
On Feb 07, 2017, at 02:15 PM, Mike Miller wrote:>Does anyone know why Python 3.6 is not the default Python 3 under the>upcoming Ubuntu Zesty, or what may be holding it back? I guess that would be me. :)>Is there anyone that could give it a nudge? It's in the repos but not as>python3:>>htt
Re: [Python-Dev] [Python-checkins] [python/cpython] 4538dd: Fix bpo-29528 Use a secure variable to stop spam (...
On Feb 11, 2017, at 08:11 PM, Andrew M. Kuchling wrote:>Are we planning to include the diffs in python-checkins e-mail, or are>they gone for good?>>(While they made the list's messages and digests larger, I liked>having the diffs because you could page through them to see what>changes were m
Re: [Python-Dev] Split Misc/NEWS into individual files
On Feb 22, 2017, at 01:27 PM, Victor Stinner wrote:>OpenStack happily fixed this issue one or two years ago with "reno":>https://pypi.python.org/pypi/reno reno looks interesting but there is at least one thing I think would need changing for us. Aside: I'm not super psyched about its requiring
Re: [Python-Dev] Split Misc/NEWS into individual files
On Feb 24, 2017, at 11:40 PM, Larry Hastings wrote:>I'm for it too. Fixing up Misc/NEWS is probably the trickiest and most>error-prone part of cutting a release. Not to mention cherry picking for older releases.>While I'm sure we can learn a lot by examining "reno", my suspicion is we'll>wa
Re: [Python-Dev] GDB macros in Misc/gdbinit are broken
On Feb 28, 2017, at 09:09 AM, Skip Montanaro wrote:>I haven't tried using Python support in gdb in a long time. I don't>know what python-gdb.py is. How is that different than>Tools/gdb/libpython.py? Is it distributed with Python? (I'm kind of>blind at work without a source distribution I can g
Re: [Python-Dev] API design: where to add async variants of existing stdlib APIs?
On Mar 01, 2017, at 10:55 AM, Victor Stinner wrote:>I suggest to create 3rd party modules on PyPI. It became easy to pull>dependencies using pip and virtualenv.>>It seems like https://github.com/aio-libs is the home of many asyncio>libraries. This is what we did for aiosmtpd, an asyncio-base
[Python-Dev] Help requested with Python 2.7 performance regression
Hello all, Over in Ubuntu, we've gotten reports about some performance regressions in Python 2.7 when moving from Trusty (14.04 LTS) to Xenial (16.04 LTS). Trusty's version is based on 2.7.6 while Xenial's version is based on 2.7.12 with bits of .13 cherry picked. We've not been able to identify
Re: [Python-Dev] Can I revoke PEP 103 (info about git)?
On Mar 08, 2017, at 10:38 PM, Nick Coghlan wrote:>Withdrawing the PEP is just a matter of submitting a PR to change the state>to Withdrawn, so it doesn't actually break any links. It's helpful to add a>short "PEP Withdrawal" section to say why it's withdrawn though, and you'd>be able to link t
Re: [Python-Dev] PEP 538: Coercing the legacy C locale to a UTF-8 based locale
On Mar 15, 2017, at 12:29 PM, Nick Coghlan wrote:>From a mainstream Linux point of view, it's not common - on systemd-managed>systems, for example, the only way to get the C locale these days is to>either specify it in /etc/locale.conf, or to set it specifically in the>environment. I think it
Re: [Python-Dev] PEP 544: Protocols
On Mar 20, 2017, at 01:00 PM, Ivan Levkivskyi wrote:>from zope.interface import Interface, Attribute, implements>>class IEmployee(Interface):>>name = Attribute("Name of employee")>>def do(work):>"""Do some work""">>class Employee(object):>
Re: [Python-Dev] Exact date of Python 2 EOL?
On Mar 23, 2017, at 09:41 AM, Victor Stinner wrote:>Can we pick an official date? Benjamin should pick the date and update PEP 373.>Ubuntu 12.04 reached its end of life after 5 years, but it seems like>Canonical also starts to offer extended support to customers:>http://www.omgubuntu.co.uk/2
Re: [Python-Dev] Exact date of Python 2 EOL?
On Mar 23, 2017, at 08:02 PM, MRAB wrote:>If you see 2/8, is that 2 August or February 8? I think that's 0.25 which doesn't look like a date to me . ISO 8601 dates please: 2020年02月08日 is unambiguous. -Barry ___ Python-Dev mailing list Python-Dev@pytho
Re: [Python-Dev] Exact date of Python 2 EOL?
On Mar 24, 2017, at 04:03 PM, Nick Coghlan wrote:>As far as I'm aware, Samba is the main remaining challenge for Fedora>Server on that front, but at least all of the libraries it depends on have>received the necessary updates to make them Python 2/3 compatible:>http://fedora.portingdb.xyz/pkg/
Re: [Python-Dev] 2017 Python Language Summit coverage
On May 25, 2017, at 08:03 AM, Jake Edge wrote:>Thanks to Larry and Barry, I was able to sit in on the Python Language>Summit again this year. The start of the coverage for that is now>available. Thanks so much for your always excellent reporting Jake. It's unfortunate that we can't invite ev
Re: [Python-Dev] PEP 7 and braces { .... } on if
On May 31, 2017, at 04:13 PM, Victor Stinner wrote:>Previous discussion which added "strongly preferred" to the PEP 7, January>2016: https://mail.python.org/pipermail/python-dev/2016-January/142746.html I had to go back to make sure I wouldn't contradict myself. +1 then, +1 now for requiring b
Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7
On May 31, 2017, at 02:09 PM, Jim Baker wrote:>But I object to a completely new feature being added to 2.7 to support the>implementation of event loop SSL usage. This feature cannot be construed as>a security fix, and therefore does not qualify as a feature that can be>added to CPython 2.7 at
Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7
On Jun 02, 2017, at 02:14 AM, Chris Angelico wrote:>But it also includes people on stable Linux distros, where they have>automatic updates provided by Red Hat or Debian or whomever, so a change like>this WILL propagate - particularly (a) as the window is three entire years,>and (b) if the chan
Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7
On Jun 01, 2017, at 07:22 PM, Victor Stinner wrote:>I can help Canonical to backport MemoryBIO *if they want* to>cherry-pick this feature ;-) (Pedantically speaking, this falls under the Ubuntu project's responsibility, not directly Canonical.) Writing the patch is only part of the process: h
Re: [Python-Dev] PEP 7 and braces { .... } on if
https://github.com/python/peps/pull/280/files On Jun 01, 2017, at 09:08 PM, Brett Cannon wrote:>If you create an issue at github.com/python/peps and assign it to me I will>get to it someday. :) pgpqhM6HQldC5.pgp Description: OpenPGP digital signature __
Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7
On Jun 03, 2017, at 02:10 AM, Nick Coghlan wrote:>* Introduce a dependency from requests onto PyOpenSSL when running in>async mode on Python 2.7 in the general case, and figure out some>other pip-specific option for ensurepip bootstrapping (like a>*private* MemoryBIO implementation, or falling
Re: [Python-Dev] PEP 7 and braces { .... } on if
On Jun 03, 2017, at 07:25 PM, Serhiy Storchaka wrote:>But the latter example continuation lines are intended at the same level as>the following block of code. I propose to make exception for that case and>allow moving an open brace to the start of the next line.>> if (type->tp_dictoffset
Re: [Python-Dev] PEP 7 and braces { .... } on if
On Jun 05, 2017, at 08:41 AM, Serhiy Storchaka wrote:>the example above), and the following code is enough readable:>> if (PyErr_WarnFormat(PyExc_DeprecationWarning, 1,> "invalid escape sequence '\\%c'",> *first_invalid_escape)
Re: [Python-Dev] PEP 7 and braces { .... } on if
On Jun 05, 2017, at 07:00 AM, Skip Montanaro wrote:>Wow, this discussion takes me back. Glad I don't have to check out>comp.lang.c to get my brace placement fix. Life is better without braces! -Barry ___ Python-Dev mailing list [email protected]
Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7
On Jun 09, 2017, at 08:43 PM, Nick Coghlan wrote:>So honestly, I'd be +1 for either approach:>>- stdlib backport to make dual-stack maintenance easier for the>current volunteers, and we'll see how things work out on the>ease-of-adoption front As I've said, I'm okay with this approach as long
Re: [Python-Dev] Impact of Namedtuple on startup time
On Jul 17, 2017, at 10:59, Raymond Hettinger wrote:> > ISTM this issue is being pressed by micro-optimizers who are being very > aggressive and not responding to actual user needs (it is more an invented > issue than a real one). Named tuple has been around for a long time and > users have
Re: [Python-Dev] Impact of Namedtuple on startup time
namedtuple is great and clever, but it’s also a bit clunky. It has a weird signature and requires a made up type name. It’s also rather unPythonic if you want to support default arguments when creating namedtuple instances. Maybe as you say, a lot of the typical use cases for namedtuples coul
Re: [Python-Dev] Impact of Namedtuple on startup time
On Jul 17, 2017, at 18:27, Greg Ewing wrote: > > Barry Warsaw wrote: >> namedtuple is great and clever, but it’s also a bit clunky. It has a weird >> signature and requires a made up type name. > > Maybe a metaclass could be used to make something > like this po
Re: [Python-Dev] Python startup time
On Jul 21, 2017, at 01:25 PM, Nikolaus Rath wrote:>That is what Emacs does, and it causes them a lot of trouble. They're>trying to move away from it at the moment, but the direction is not yet>clear. The keyword is "unexec", and it wrecks havoc with malloc. Emacs has been unexec'ing for as lon
Re: [Python-Dev] startup time repeated? why not daemon
On Jul 20, 2017, at 03:16 PM, Eric Snow wrote:>Relatedly, at PyCon this year Barry and I were talking about the idea of>bootstrapping the interpreter from a memory snapshot on disk, rather than>from scatch (thus drastically reducing the number of IO events). The TPI (Terrible Python Idea) I ha
[Python-Dev] Scope, not context? (was Re: PEP 550 v3 naming)
Guido van Rossum wrote:> On Tue, Aug 22, 2017 at 7:12 PM, Nathaniel Smith wrote:> > I worry that that's going to lead more people astray thinking this has> something to do with contextlib, which it really doesn't (it's much more> closely related to threading.local()). This is my problem with
Re: [Python-Dev] Scope, not context? (was Re: PEP 550 v3 naming)
On Aug 24, 2017, at 10:23, Yury Selivanov wrote: > > On Thu, Aug 24, 2017 at 9:52 AM, Barry Warsaw wrote: >> Guido van Rossum wrote: >>> On Tue, Aug 22, 2017 at 7:12 PM, Nathaniel Smith wrote: >>> >>> I worry that that's going to lead more people
Re: [Python-Dev] Scope, not context? (was Re: PEP 550 v3 naming)
On Aug 24, 2017, at 16:01, francismb wrote: > On 08/24/2017 03:52 PM, Barry Warsaw wrote: >> Guido van Rossum wrote: >>> On Tue, Aug 22, 2017 at 7:12 PM, Nathaniel Smith wrote: >>> >>> I worry that that's going to lead more people astray thinking thi
Re: [Python-Dev] Scope, not context? (was Re: PEP 550 v3 naming)
On Aug 25, 2017, at 10:18, Yury Selivanov wrote:> > I has a similar idea when I discovered that PEP 550 can't be used> directly to fix sys.std* streams redirection. Another idea:> > 1. We alter PyModule to make it possible to add properties (descriptor> protocol, or we implement custom __ge
Re: [Python-Dev] PEP 550 v4
I agree with David; this PEP has really gotten to a great place and the new organization makes it much easier to understand.> On Aug 25, 2017, at 22:19, Ethan Furman wrote:> > Why "lookup" and not "get" ? Many APIs use "get" and it's functionality is > well understood. I have the same ques
Re: [Python-Dev] Scope, not context? (was Re: PEP 550 v3 naming)
On Aug 26, 2017, at 12:43, francismb wrote:> >>> I propose RaymondLuxuryYach_t, but we’ll have to pronounce it >>> ThroatwobblerMangrove.>> >> Sorry, but I think we should prononce it ThroatwobblerMangrove.>> > too hard to pronounce but at least is unique, I would prefer thredarena> but I
Re: [Python-Dev] PEP 550 v4
On Aug 26, 2017, at 14:15, Yury Selivanov wrote:> > Elvis just added it:> https://www.python.org/dev/peps/pep-0550/#replication-of-threading-local-interface Thanks, that’s exactly what I was looking for. Great summary of the issue.> >> That said, if we have to use method lookup, then I agre
Re: [Python-Dev] Pep 550 and None/masking
On Aug 28, 2017, at 11:50, Yury Selivanov wrote:> For checking if a context variable has a value in the topmost LC, we> can add two new keyword arguments to the "ContextVar.lookup()" method:> > ContextVar.lookup(*, default=None, topmost=False)> > If `topmost` is set to `True`, `lookup` wi
[Python-Dev] PEP 553: Built-in debug()
I’ve written a PEP proposing the addition of a new built-in function called debug(). Adding this to your code would invoke a debugger through the hook function sys.debughook(). Like the existing sys.displayhook() and sys.excepthook(), you can change sys.debughook() to point to the debugger of
Re: [Python-Dev] PEP 553: Built-in debug()
On Sep 5, 2017, at 20:15, Guido van Rossum wrote:> > Yeah, I like the idea, but I don't like the debug() name -- IIRC there's a > helper named debug() in some codebase I know of that prints its arguments > under certain circumstances.> > On Tue, Sep 5, 2017 at 7:58 PM, Nathaniel Smith wrote
Re: [Python-Dev] PEP 553: Built-in debug()
On Sep 5, 2017, at 19:31, Giampaolo Rodola' wrote:> > True. Personally I have a shortcut in my IDE (Sublime) so I when I type "pdb" > -> TAB it auto completes it.> > Somehow I think debug() would make this a bit harder as it's more likely a > "debug()" line will pass unnoticed.> For this re
Re: [Python-Dev] PEP 553: Built-in debug()
On Sep 6, 2017, at 07:46, Guido van Rossum wrote:> > IIRC they indeed insinuate debug() into the builtins. My suggestion is also > breakpoint(). breakpoint() it is then! I’ll rename the sys hooks too, but keep the naming scheme of the existing sys hooks. Cheers, -Barry signature.asc Desc
Re: [Python-Dev] PEP 553: Built-in debug()
On Sep 6, 2017, at 10:19, Guido van Rossum wrote:> > 99% of the time I use a debugger I use pdb.set_trace(). The pm() stuff is > typically useful for debugging small, simple programs only -- complex > programs likely hide the exception somewhere (after logging it) so there's > nothing for pdb
Re: [Python-Dev] PEP 553: Built-in debug()
On Sep 6, 2017, at 10:14, Fabio Zadrozny wrote:> > I think it's a nice idea. Great!> Related to the name, on the windows c++ there's "DebugBreak": > https://msdn.microsoft.com/en-us/library/windows/desktop/ms679297(v=vs.85).aspx,> which I think is a better name (so, it'd be debug_break fo
Re: [Python-Dev] PEP 553: Built-in debug()
On Sep 6, 2017, at 14:59, Terry Reedy wrote:> > Currently, the debugger is started in response to a menu seletion in the IDLE > process while the python process is idle. One reason for the 'idle' > requirement' is because when code is exec-uting, the loop that reads > commands, executes them
Re: [Python-Dev] To reduce Python "application" startup time
On Sep 6, 2017, at 00:42, INADA Naoki wrote:> Additionally, faster startup time (and smaller memory footprint) is good> for even Web applications.> For example, CGI is still comfortable tool sometimes.> Another example is GAE/Python.> > Anyway, I think researching import tree of popular lib
Re: [Python-Dev] PEP 553: Built-in debug()
On Sep 6, 2017, at 16:55, Fernando Perez wrote:> > If I may suggest a small API tweak, I think it would be useful if > breakpoint() accepted an optional header argument. In IPython, the equivalent > for non-postmortem debugging is IPython.embed, which can be given a header. > This is useful t