Re: [Python-Dev] Why aren't decorators just expressions?

On Sep 16, 2017, at 02:39, Larry Hastings wrote: > I'm not proposing that we allow arbitrary expressions as decorators... well, > I'm not doing that yet at least. But like I said, the syntax has been this > way for 13 years and I don't recall anybody complaining. Indeed,

Re: [Python-Dev] PEP 557: Data Classes

On Sep 14, 2017, at 09:56, Mike Miller wrote: > Record is the most common name for this ubiquitous concept. Mind if we call them Eric Classes to keep it clear? Because if its name is not Eric Classes, it will cause a little confusion. g’day-bruce-ly y’rs, -Barry

[Python-Dev] PEP 553, v3

Here’s an update to PEP 553, which makes $PYTHONBREAKPOINT a first class feature. I’ve also updated PR #3355 with the implementation to match. Cheers, -Barry PEP: 553 Title: Built-in breakpoint() Author: Barry Warsaw <ba...@python.org> Status: Draft Type: Standards Track Content-Type:

Re: [Python-Dev] PEP 557: Data Classes

On Sep 11, 2017, at 19:16, Guido van Rossum wrote: > > Or we could just have two arguments, eq= and order=, and some > rule so that you only need to specify one or the other but not both. (E.g. > order=True implies eq=True.) That seems better than needing new constants >

Re: [Python-Dev] PEP 557: Data Classes

On Sep 11, 2017, at 18:36, Eric V. Smith wrote: > So if we don't do enums, I think the choices are ints, strs, or maybe > True/False/None. Do you have a preference here? > > If int or str, I assume we'd want module-level constants. > > I like the name compare=, and 3 values

Re: [Python-Dev] breakpoint() and $PYTHONBREAKPOINT

On Sep 11, 2017, at 18:15, Nathaniel Smith wrote: > Compared to checking it on each call to sys.breakpointhook(), I guess > the two user-visible differences in behavior would be: > > - whether mutating os.environ["PYTHONBREAKPOINT"] inside the process > affects future calls. I

Re: [Python-Dev] breakpoint() and $PYTHONBREAKPOINT

On Sep 10, 2017, at 13:46, Nathaniel Smith <n...@pobox.com> wrote: > > On Sun, Sep 10, 2017 at 12:06 PM, Barry Warsaw <ba...@python.org> wrote: >> For PEP 553, I think it’s a good idea to support the environment variable >> $PYTHONBREAKPOINT[*] but I’m stuck on

Re: [Python-Dev] breakpoint() and $PYTHONBREAKPOINT

On Sep 10, 2017, at 12:16, Guido van Rossum wrote: > > I think programmatic overrides should be able to decide for themselves if > they want to honor PYTHONBREAKPOINT or not, since I can imagine use cases > that go both ways. So it should be checked in sys.breakpointhook().

Re: [Python-Dev] PEP 557: Data Classes

On Sep 11, 2017, at 16:51, Mike Miller wrote: > > On 2017-09-11 05:26, Eric V. Smith wrote: >> On 9/10/17 10:27 PM, Raymond Hettinger wrote: > > I've typically used these type of objects as records. When in an irreverent > mood I've called them bags. I’ve used ‘bag’

Re: [Python-Dev] PEP 557: Data Classes

On Sep 11, 2017, at 15:16, Ethan Furman wrote: >> >> enum Compare(enum.Enum): >> none = 1 >> unordered = 2 >> ordered = 3 > > I like the enum idea (suprise! ;) but I would suggest "equal" or "equivalent" > instead of "unordered"; better to say what they are

Re: [Python-Dev] PEP 557: Data Classes

On Sep 10, 2017, at 20:08, Nathaniel Smith wrote: > > I've sometimes wished that attrs let me control whether it generated equality > methods (eq/ne/hash) separately from ordering methods (lt/gt/...). Maybe the > cmp= argument should take an enum with options

Re: [Python-Dev] PEP 559 - built-in noop()

On Sep 10, 2017, at 14:39, Chris Angelico wrote: > > As a language change, definitely not. But I like this idea for > PYTHONBREAKPOINT. You set it to the name of a function, or to "pass" > if you want nothing to be done. It's a special case that can't > possibly conflict with

[Python-Dev] breakpoint() and $PYTHONBREAKPOINT

For PEP 553, I think it’s a good idea to support the environment variable $PYTHONBREAKPOINT[*] but I’m stuck on a design question, so I’d like to get some feedback. Should $PYTHONBREAKPOINT be consulted in breakpoint() or in sys.breakpointhook()? If we support it in breakpoint() then it means

Re: [Python-Dev] PEP 559 - built-in noop()

On Sep 9, 2017, at 15:12, Guido van Rossum wrote: > > I can't tell whether this was meant seriously, but I don't think it's worth > it. People can easily write their own dummy function and give it any damn > semantics they want. Let's reject the PEP. Alrighty then! (Yes, it

[Python-Dev] PEP 559 - built-in noop()

I couldn’t resist one more PEP from the Core sprint. I won’t reveal where or how this one came to me. -Barry PEP: 559 Title: Built-in noop() Author: Barry Warsaw <ba...@python.org> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 2017-09-08 Python-Version: 3.7 Post-H

Re: [Python-Dev] PEP 553 V2 - builtin breakpoint() (was Re: PEP 553: Built-in debug())

On Sep 7, 2017, at 19:34, Nick Coghlan wrote: > Now that you put it that way, it occurs to me that CI environments > could set "PYTHONBREAKPOINTHOOK=sys:exit" to make breakpoint() an > immediate failure rather than halting the CI run waiting for input > that will never

Re: [Python-Dev] PEP 553: Built-in debug()

On Sep 7, 2017, at 18:03, Fernando Perez wrote: > Ah, perfect! I've subscribed to the PR on github and can pitch in there > further if my input is of any use. Awesome, thanks! -Barry signature.asc Description: Message signed with OpenPGP

Re: [Python-Dev] PEP 553: Built-in debug()

On Sep 7, 2017, at 16:19, Terry Reedy wrote: > I think breakpoint() should have a db= parameter so one can select a debugger > in one removable line. The sys interface is more useful for IDEs to change > the default, possible with other args (like breakpoints and colors)

Re: [Python-Dev] PEP 553 V2 - builtin breakpoint() (was Re: PEP 553: Built-in debug())

On Sep 7, 2017, at 18:12, Nick Coghlan wrote: > > Related to this is the suggestion that we make the default > sys.breakpointhook() a no-op, so that accidentally checking in calls > to breakpoint() won' t hang CI systems. > > Then folks that wanted to use the functionality

Re: [Python-Dev] PEP 552: deterministic pycs

On Sep 7, 2017, at 16:58, Gregory P. Smith wrote: > Input from OS package distributors would be interesting. Would they use this? I suspect it won’t be that interesting to the Debian ecosystem, since we generate pyc files on package install. We do that because we can support

Re: [Python-Dev] PEP 553: Built-in debug()

On Sep 7, 2017, at 14:25, Barry Warsaw <ba...@python.org> wrote: > > I’ll see what it takes to add `header` to pdb.set_trace(), but I’ll do that > as a separate PR (i.e. not as part of this PEP). Turns out to be pretty easy. https://bugs.python.org/issue31389 https://github.com

Re: [Python-Dev] PEP 553: Built-in debug()

On Sep 7, 2017, at 12:09, Fernando Perez wrote: >> The PEP has an open issue regarding breakpoint() taking *args and **kws, >> which would just be passed through the call stack. It sounds like you’d be >> in favor of that enhancement. > > If you go witht the `(*a, **k)`

Re: [Python-Dev] PEP 553: Built-in debug()

On Sep 7, 2017, at 13:52, Terry Reedy wrote: > pdb.set_trace is a public and stable interface. IDLE's is private and likely > to be initially unstable. I can imagine that the function that I would want > to bind to sys.__breakpoint__ would be a bound method To be

Re: [Python-Dev] PEP 553: Built-in debug()

On Sep 7, 2017, at 14:04, Fred Drake wrote: > > On Thu, Sep 7, 2017 at 4:52 PM, Terry Reedy wrote: >> Environmental variables tend to be a pain on Windows and nigh unusable by >> beginners. Leaving that aside, I see these problems with trying to use one >>

[Python-Dev] PEP 553 V2 - builtin breakpoint() (was Re: PEP 553: Built-in debug())

. Cheers, -Barry PEP: 553 Title: Built-in breakpoint() Author: Barry Warsaw <ba...@python.org> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 2017-09-05 Python-Version: 3.7 Post-History: 2017-09-05, 2017-09-07 Abstract This PEP proposes adding a new built-in fu

Re: [Python-Dev] PEP 553: Built-in debug()

On Sep 7, 2017, at 10:00, Christian Heimes wrote: > Setuptools' entry points [1] use colon between import and function, e.g. > "pdb:set_trace" would import pdb and then execute set_trace. The > approach can be augmented to allow calling a class method, too. > > So > >

Re: [Python-Dev] PEP 553: Built-in debug()

On Sep 7, 2017, at 07:46, Guido van Rossum wrote: > Without following all this (or the PEP, yet) super exactly, does this mean > you are satisfied with what the PEP currently proposes or would you like > changes? It's a little unclear from what you wrote. I’m also unsure

Re: [Python-Dev] PEP 553: Built-in debug()

On Sep 6, 2017, at 23:10, Terry Reedy wrote: > > Environmental variables are set to strings, not objects. It is not clear how > you intend to handle the conversion. The environment variable names a module import path. Without quibbling about the details of the syntax

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

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

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 >

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,

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

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

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

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,

[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 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

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

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

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.

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,

Re: [Python-Dev] Scope, not context? (was Re: PEP 550 v3 naming)

On Aug 24, 2017, at 16:01, francismb <franci...@email.de> 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 <n...@pobox.com> wrote: >>> >>> I worry that that's go

Re: [Python-Dev] Scope, not context? (was Re: PEP 550 v3 naming)

On Aug 24, 2017, at 10:23, Yury Selivanov <yselivanov...@gmail.com> wrote: > > On Thu, Aug 24, 2017 at 9:52 AM, Barry Warsaw <ba...@python.org> wrote: >> Guido van Rossum wrote: >>> On Tue, Aug 22, 2017 at 7:12 PM, Nathaniel Smith <n...@pobox.com> wrote: >

[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

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

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

Re: [Python-Dev] Impact of Namedtuple on startup time

On Jul 17, 2017, at 18:27, Greg Ewing <greg.ew...@canterbury.ac.nz> 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

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

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

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

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

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'", >

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] 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

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 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:

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

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] 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

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

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:

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

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:

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] 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

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

[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] 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

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

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

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

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

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: >

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

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] 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

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

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-*

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

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] 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

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

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.

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

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

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

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

[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] 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

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

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 <ba...@python.org> 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 t

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

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

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

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

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

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] 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

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

<    1   2   3   4   5   6   7   8   9   10   >