Re: [Python-Dev] Better support for consuming vendored packages

On Mar 22, 2018, at 12:33, Oleg Broytman <p...@phdru.name> wrote: > > On Thu, Mar 22, 2018 at 12:30:02PM -0700, Barry Warsaw <ba...@python.org> > wrote: >> Developers are mostly going to use pip, and maybe a requirements.txt, > > +virtual envs to avoid problem

Re: [Python-Dev] Better support for consuming vendored packages

On Mar 22, 2018, at 09:58, Gregory Szorc wrote: > > Not all consumers of Python packages wish to consume Python packages in the > common `pip install ` + `import ` manner. Some Python > applications may wish to vendor Python package dependencies such that known >

Re: [Python-Dev] Any way to only receive emails for threads that I am participating in?

On Mar 2, 2018, at 20:41, Dan Stromberg wrote: > > Maybe gmane combined with a threaded newsreader (NNTP client) would be > close enough? While I guzzle the firehose of python-dev from my inbox, Gmane+NNTP is how I read many other Python mailing lists, including

Re: [Python-Dev] How is the GitHub workflow working for people?

On Feb 22, 2018, at 09:09, Eric Snow wrote: > > I had exactly that experience on one particularly large Go project (on > GitHub, with slow CI, driven by bots). One thing that’s nice to set up if you can is multiple, parallel, independent CI runs. E.g. if your full

Re: [Python-Dev] How is the GitHub workflow working for people?

> On Feb 22, 2018, at 08:08, Antoine Pitrou wrote: > > That's a fair point I hadn't considered. OTOH the style issues I > usually comment on as a reviewer aren't the kind that would be caught > by an automated style check (I tend to ask for comments or docstrings, > or be

Re: [Python-Dev] How is the GitHub workflow working for people?

On Feb 22, 2018, at 02:12, Antoine Pitrou wrote: > Everytime I contribute to a project which has automatic style checks in > CI, I find myself having to push pointless "cleanup" commits because > the CI is barking at me for some ridiculous reason (such as putting two >

Re: [Python-Dev] How is the GitHub workflow working for people?

On Feb 21, 2018, at 19:03, Dan Stromberg wrote: > > Is flake8 that much better than pylint, that pylint wouldn't even be > discussed? I honestly don’t use pylint all that much these days, but when I was evaluating them years ago, I found pylint to be too noisy about

Re: [Python-Dev] The `for y in [x]` idiom in comprehensions

On Feb 22, 2018, at 11:04, Serhiy Storchaka wrote: > > Stephan Houben proposed an idiom which looks similar to new hypothetic syntax: > >result = [y + g(y) for x in range(10) for y in [f(x)]] > > `for y in [expr]` in a comprehension means just assigning expr to y. I

Re: [Python-Dev] Making "Provisional" an explicit PEP state

On Feb 20, 2018, at 22:42, Nick Coghlan wrote: > > In the current PEP workflow, provisionally accepted PEPs are marked as > "Accepted", and remain in that state until they're declared stable and > moved to Final. I left a review on the PR, but the substance of the changes

Re: [Python-Dev] How is the GitHub workflow working for people?

On Feb 21, 2018, at 13:22, Guido van Rossum wrote: > > I'm willing to reconsider if there's a good enough tool. Ditto for C code (or > do we already do it for C?). For Python code, flake8 --possibly with our own custom plugins— is the way to go. It would probably take some

Re: [Python-Dev] Is object the most base type? (bpo-20285)

On Feb 2, 2018, at 02:25, Steven D'Aprano wrote: > > On Fri, Feb 02, 2018 at 01:53:00AM -0500, Terry Reedy wrote: > object.__doc__ >> 'The most base type’ Clearly that’s a typo. It should be: “The most bass type” as in: "It all starts with the bass, the most important

Re: [Python-Dev] Why is Python for Windows compiled with MSVC?

On Feb 1, 2018, at 04:19, Oleg Sivokon wrote: > > Oh, so this is the real reason... well, corporate interests are hard to argue > against. But, this is an interesting statistic nevertheless. Thanks for > letting me know. Maybe it hasn’t happened because no volunteer has

Re: [Python-Dev] Guido's Python 1.0.0 Announcement from 27 Jan 1994

On Jan 27, 2018, at 21:45, Guido van Rossum wrote: > > For me personally, the fondest memories are of 1.5.2, which Paul Everitt > declared, while we were well into 2.x territory, was still the best Python > ever. (I didn't agree, but 1.5.2 did serve us very well for a long

Re: [Python-Dev] [python-committers] Welcome the 3.8 and 3.9 Release Manager - Łukasz Langa!

On Jan 27, 2018, at 17:04, Guido van Rossum > wrote: > > Hardly a surprising choice! Congrats, Łukasz. (And never forget that at every > Mac OS X upgrade I have to install the extended keyboard just so I can type > that darn Ł. :-) Heh, I *just*

[Python-Dev] Welcome the 3.8 and 3.9 Release Manager - Łukasz Langa!

As Ned just announced, Python 3.7 is very soon to enter beta 1 and thus feature freeze. I think we can all give Ned a huge round of applause for his amazing work as Release Manager for Python 3.6 and 3.7. Let’s also give him all the support he needs to make 3.7 the best version yet. As is

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

On Jan 25, 2018, at 16:55, Mariatta Wijaya wrote: > My problem has been that I almost always still need to rewrite the commit > message. > Especially when someone wrote "fix a typo" or "fix several typos". > > If it automatically merges, then there's no opportunity

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

On Jan 25, 2018, at 13:38, Mariatta Wijaya wrote: > > +1 for the mergebot! :) Yes, +1 from me too. As you know, GitLab has the option to “merge when CI completes successfully” and it’s a great workflow. Once I’ve reviewed and approved the branch, I can hit this

Re: [Python-Dev] Unique loader per module

On Jan 05, 2018, at 05:12 PM, Nick Coghlan wrote: >I think the main reason you're seeing a problem here is because >ResourceReader has currently been designed to be implemented directly >by loaders, rather than being a subcomponent that you can request >*from* a loader. > >If you instead had an

Re: [Python-Dev] Positional-only parameters in Python

On Jan 17, 2018, at 08:14, Serhiy Storchaka wrote: > > The main problem -- designing a syntax that does not look ugly. I think there > are too small time is left before features freezing for experimenting with > it. It would be better to make such changes at the early

Re: [Python-Dev] Deprecate PEP 370 Per user site-packages directory?

On Jan 13, 2018, at 12:06, Christian Heimes wrote: > These days a lot of packages are using setuptools' entry points to > create console scripts. Entry point have no option to create a console > script with -s or -I flag. On my system, only 40 out of 360 scripts in >

Re: [Python-Dev] Deprecate PEP 370 Per user site-packages directory?

On Jan 13, 2018, at 11:12, Miro Hrončok wrote: > > We would very much like to see --user the default rather than having it > removed. Very much +1. In Debian/Ubuntu we’ve carried patches to do exactly that for years, and I think our users have been very happy about it.

Re: [Python-Dev] Whatever happened to 'nonlocal x = y'?

On Jan 6, 2018, at 11:43, Guido van Rossum wrote: > > Maybe we should not delete them outright but add something like "(UPDATE: > during later discussions it was decided that this feature shouldn't be > added.)" +1 -Barry signature.asc Description: Message signed with

[Python-Dev] Unique loader per module

We have what I think is one last design question for importlib.resources. https://gitlab.com/python-devs/importlib_resources/issues/49 The problem is that the ResourceReader ABC omits the package from the function signatures, so that on a compatible loader, you only need to specify the

Re: [Python-Dev] Documenting types outside of typing

On Dec 27, 2017, at 18:59, Ivan Levkivskyi wrote: > > FWIW the same problem was discussed a year ago when documenting typing. At > that time the discussion was not conclusive, > so that some types use class:: directive while other use data:: directive. At > that time

[Python-Dev] Documenting types outside of typing

In his review of PR#4911, Antoine points to the documentation of two type definitions in importlib.resources, Package and Resource. https://github.com/python/cpython/pull/4911/files#diff-2a479c407f7177f3d7cb876f244e47bcR804 One question is what markup to use for type definitions. I’m using

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Dec 19, 2017, at 20:32, Nathaniel Smith wrote: > I guess the underlying issue here is partly the question of what the > pprint module is for. In my understanding, it's primarily a tool for > debugging/introspecting Python programs, and the reason it talks about > "valid input

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Dec 18, 2017, at 22:37, Nathaniel Smith wrote: > Wait, what? Why would changing pprint (so that it accurately reflects > dict's new underlying semantics!) be a breaking change? Are you > suggesting it shouldn't be changed in 3.7? As others have pointed out, exactly because

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Dec 18, 2017, at 21:11, Chris Barker wrote: > Will changing pprint be considered a breaking change? Yes, definitely. -Barry signature.asc Description: Message signed with OpenPGP ___ Python-Dev mailing list

Re: [Python-Dev] Is static typing still optional?

On Dec 18, 2017, at 21:41, Chris Barker wrote: > > TL;DR: > My point is that having type annotation syntax required for something in the > stdlib is a significant step toward "normalizing" type hinting in Python. > Whether that's a good idea or not is a judgement call,

Re: [Python-Dev] New crash in test_embed on macOS 10.12

On Dec 15, 2017, at 15:14, Raymond Hettinger wrote: > > I saw this same test failure. After a "make distclean", it went away. Dang, not for me. -Barry signature.asc Description: Message signed with OpenPGP ___

[Python-Dev] New crash in test_embed on macOS 10.12

I haven’t bisected this yet, but with git head, built and tested on macOS 10.12.6 and Xcode 9.2, I’m seeing this crash in test_embed: == FAIL: test_bpo20891 (test.test_embed.EmbeddingTests)

Re: [Python-Dev] Mostly Official Python Development Container Image

On Dec 10, 2017, at 19:36, Ryan Gonzalez wrote: > > Question: why is this using GitLab while CPython itself is using GitHub + > Travis? Mostly because Brett gave me the option to use GitLab for importlib_resources, and this grew out of that. Enjoy! overturn-pep-507-ly

[Python-Dev] Mostly Official Python Development Container Image

As part of our work on importlib_resources, and with some fantastic help from Abhilash Raj, we now have a mostly official Python development container image that you can use for CI testing and other development purposes. This image is based on Ubuntu 16.04 LTS and provides the latest stable

[Python-Dev] Announcing importlib_resources 0.1

Brett and I have been working on a little skunkworks project for a few weeks, and it’s now time to announce the first release. We’re calling it importlib_resources and its intent is to replace the “Basic Resource Access” APIs of pkg_resources with more efficient implementations based directly

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

On Dec 5, 2017, at 13:24, Guido van Rossum wrote: > But the whole point of the PEP is that it only warns about deprecations in > code over which the user has control -- likely __main__ is their own code, > and they *can* handle it. I’m not so sure how true that is. I have

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

On Nov 29, 2017, at 12:40, David Mertz wrote: > I think some syntax could be possible to only "catch" some exceptions and let > others propagate. Maybe: > >val = name.strip()[4:].upper() except (AttributeError, KeyError): -1 > > I don't really like throwing a colon in an

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

> On Nov 28, 2017, at 15:59, Paul Moore <p.f.mo...@gmail.com> wrote: > > On 28 November 2017 at 20:38, Barry Warsaw <ba...@python.org> wrote: >> I had occasional to speak with someone very involved in Rust development. >> They have a process roughly similar t

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

On Nov 28, 2017, at 15:31, Raymond Hettinger wrote: > Put me down for a strong -1. The proposal would occasionally save a few > keystokes but comes at the expense of giving Python a more Perlish look and a > more arcane feel. I am also -1. > One of the things

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

On Nov 22, 2017, at 19:32, Victor Stinner wrote: > > Aha, contextlib.nullcontext() was just added, cool! So, if I rewrite PEP 559 in terms of decorators it won’t get rejected? from functools import wraps def noop(func): @wraps(func) def wrapper(*args, **kws):

Re: [Python-Dev] Show DeprecationWarning in debug mode?

On Nov 17, 2017, at 20:22, Victor Stinner wrote: > > Or maybe we should start adding new modes like -X > all-warnings-except-PendingDeprecationWarning, -X > I-really-really-love-warnings and -X warnings-hater, as Barry > proposed? Well, if I can’t convince you about a

Re: [Python-Dev] Add a developer mode to Python: -X dev command line option

On Nov 16, 2017, at 09:47, Yury Selivanov wrote: > Let's keep it simple. I'm big -1 on adding different "debug levels", > they are always confusing. Oh, this one’s easy. -X dev == some debugging -X deve == a little more -X devel == give it to me! -X

Re: [Python-Dev] Add a developer mode to Python: -X dev command line option

On Nov 15, 2017, at 21:57, Victor Stinner wrote: > > Since Brett and Nick like the idea and nobody complained against it, I > implemented the -X dev option: Cool! What would you think about printing a summary of the settings under the standard banner when you run the

Re: [Python-Dev] Add a developer mode to Python: -X dev command line option

On Nov 16, 2017, at 06:53, Victor Stinner wrote: > What do you think? Is it ok to include asyncio in the global "developer mode"? I’m +1 on that, and the performance hit doesn’t bother me for a developer mode. -Barry signature.asc Description: Message signed with

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On Nov 8, 2017, at 23:57, Nick Coghlan wrote: > Putting that quibble first: could we adjust the feature flag to be > either "from __future__ import lazy_annotations" or "from __future__ > import str_annotations"? > > Every time I see "from __future__ import annotations" I

Re: [Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff

On Nov 9, 2017, at 07:27, Tres Seaver wrote: > IIUC, that would be as expected: you would see the warnings when running > your test suite exercising that imported code (which should run with all > warnings enabled), but not when running the app. > > Seems like a

Re: [Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff

On Nov 8, 2017, at 16:10, Nick Coghlan wrote: > The rationale for that change was so that end users of applications > that merely happened to be written in Python wouldn't see deprecation > warnings when Linux distros (or the end user) updated to a new Python > version.

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Nov 8, 2017, at 12:02, Guido van Rossum wrote: > > I hadn't seen that, but it requires too much cooperation of library owners. Actually, mostly just setuptools and as Paul points out, pip. Cheers, -Barry signature.asc Description: Message signed with OpenPGP

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Nov 8, 2017, at 08:47, Guido van Rossum wrote: > > You seem to have missed Nick's posts where he clearly accepts that a middle > ground is necessary. R D Murray is also still unconvinced. (And obviously I > myself am against reverting to the behavior from 7 years ago.) If

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

Antoine Pitrou wrote: > On Mon, 6 Nov 2017 23:23:25 +1000 >> - tweak the default warning filters to turn DeprecationWarning back on >> for __main__ only > > Thats sounds error-prone. I'd rather have them on by default > everywhere. If DeprecationWarnings were on by default, and setuptools were

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Nov 7, 2017, at 16:15, Chris Barker - NOAA Federal wrote: > Actually, there is a LOT of code out there that expects reference counting. I > know a lot of my code does. So if cPython does abandon it some day, there > will be issues. I see this all the time in code

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Nov 7, 2017, at 13:34, Jakub Wilk wrote: > "import async" would indeed cause deprecation warning, but that's not what > ldap3 does. The only uses of the now-keyword "async" in their codebase are > like this: > > from ..strategy.async import AsyncStrategy > from .async

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Nov 7, 2017, at 12:35, Paul G wrote: > > If dictionary order is *not* guaranteed in the spec and the dictionary order > isn't randomized (which I think everyone agrees is a bit messed up), it would > probably be useful if you could enable "random order mode" in CPython, so

Re: [Python-Dev] The current dict is not an "OrderedDict"

Antoine Pitrou wrote: > Well... It really depends what kind of problem you're solving. I > certainly delete or pop items from dicts quite often. > > Let's not claim that deleting items from a dict is a rare or advanced > feature. It is not. +1. It's a pretty common pattern for handling

Re: [Python-Dev] Remove typing from the stdlib

On Nov 7, 2017, at 10:41, Lukasz Langa wrote: > 3. Does that mean that Debian is going to rip it out and make people install > a `python-typing` .deb? Sadly, probably yes. We need to figure out what that > means for us. Maybe. Full disclosure, I’ve recently scaled back my

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Nov 7, 2017, at 09:39, Paul Sokolovsky wrote: > So, the problem is that there's no "Python language spec”. There is a language specification: https://docs.python.org/3/reference/index.html But there are still corners that are undocumented, or topics that are

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Nov 7, 2017, at 05:44, Paul Moore wrote: > If you're a user and your application developer didn't do (1) or a > library developer developing one of the libraries your application > developer chose to use didn't do (2), you're hosed. If you're a user > who works in an

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Nov 7, 2017, at 01:51, Petr Viktorin wrote: > > When I explained this in 3.5, dicts rearranging themselves seemed quite weird > to the newcomers. > This year, I'm not looking forward to saying that dicts behave "intuitively", > but you shouldn't rely on that, because

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Nov 6, 2017, at 22:33, Steven D'Aprano wrote: > I think it would be reasonable to say that builtin dicts only maintain > insertion order for insertions, lookups, and changing the value. Any > mutation which deletes keys may arbitrarily re-order the dict. > > If the user

Re: [Python-Dev] The current dict is not an "OrderedDict"

On Nov 7, 2017, at 07:12, Antoine Pitrou wrote: > The problem is this is taking things to a level of precision that makes > the guarantee tedious to remember and reason about. > > The only thing that's friendly to (non-expert) users is either "dicts > are always ordered [by

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

Nick Coghlan wrote: > On the 12-weeks-to-3.7-feature-freeze thread, Jose Bueno & I both > mistakenly though the async/await deprecation warnings were missing > from 3.6. Sometimes the universe just throws synchronicity right in your face. I'm working on building an internal tool against Python

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Nov 6, 2017, at 11:23, Paul G wrote: > > Is there a major objection to just adding in explicit syntax for > order-preserving dictionaries? I don’t think new syntax is necessary. We already have OrderedDict, which to me is a perfectly sensible way to spell “I need a

Re: [Python-Dev] Allow annotations using basic types in the stdlib?

On Nov 6, 2017, at 08:02, Victor Stinner wrote: > > While discussions on the typing module are still hot, what do you > think of allowing annotations in the standard libraries, but limited > to a few basic types: I’m still -1 on adding annotations to the stdlib,

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Nov 6, 2017, at 02:18, Paul Sokolovsky wrote: > What it will lead to is further fragmentation of the community. Python2 > vs Python3 split is far from being over, and now there're splits > between: > > * people who use "yield from" vs "await" > * people who use f-strings

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Nov 5, 2017, at 20:47, Nick Coghlan wrote: >> warnings.silence_deprecations() >> python -X silence-deprecations >> PYTHONSILENCEDEPRECATIONS=x > > It could be interesting to combine this with Tim's suggestion of > putting an upper version limit on the silencing, so the

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Nov 5, 2017, at 23:08, Serhiy Storchaka wrote: > Following issues on GitHub related to new Python releases I have found that > many projects try to fix deprecation warning, but there are projects that are > surprised by ending of deprecation periods and removing

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Nov 5, 2017, at 18:05, Nick Coghlan wrote: > So my proposal is simple (and not really new): let's revert back to > the way things were in 2.6 and earlier, with DeprecationWarning being > visible by default +1 > As part of this though, I'd suggest amending the

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Nov 4, 2017, at 11:35, Guido van Rossum wrote: > > This sounds reasonable -- I think when we introduced this in 3.6 we were > worried that other implementations (e.g. Jython) would have a problem with > this, but AFAIK they've reported back that they can do this just fine.

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On Nov 3, 2017, at 17:09, Luca Sbardella wrote: > > Impressive stats! I didn’t know this command, thanks! Neither did I until a day or so ago. I already only want to use Python 3.7. :) -Barry signature.asc Description: Message signed with OpenPGP

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On Nov 2, 2017, at 23:22, Nick Coghlan wrote: > Another point worth noting is that merely importing the typing module > is expensive: > > $ python -m perf timeit -s "from importlib import reload; import > typing" "reload(typing)" > . > Mean +- std dev:

Re: [Python-Dev] Remove typing from the stdlib

On Nov 3, 2017, at 10:00, Steve Dower wrote: > > On 03Nov2017 0915, Victor Stinner wrote: >> Hi, >> 2017-11-03 15:36 GMT+01:00 Guido van Rossum : >>> Maybe we should remove typing from the stdlib? >>> https://github.com/python/typing/issues/495 >> I'm

Re: [Python-Dev] Migrate python-dev to Mailman 3?

On Nov 1, 2017, at 19:42, Guido van Rossum wrote: > > Maybe we should try it on some other list too? I know it works "in principle" > and I'd love for all Python mailing lists to migrate, but I'd like to have > some more experience with community mailing lists before tackling

Re: [Python-Dev] Migrate python-dev to Mailman 3?

On Nov 1, 2017, at 18:49, Mariatta Wijaya wrote: > > Anything I can do to help make the migration to MM3 + HyperKitty happen? :) Thanks for the offer Mariatta! Assuming this is something we want to go through with, probably the best way to get there is to work with

Re: [Python-Dev] Migrate python-dev to Mailman 3?

On Oct 29, 2017, at 11:42, Serhiy Storchaka wrote: > Does Mailman 3 provide a NNTP interface? The NNTP interface of Gmane still > works, but it can be switched off at any time. It would be more reliable to > not depend on an unstable third-party service. I use the NNTP

[Python-Dev] PEP Post-History

We’ve made a small change to the PEP process which may affect readers of python-list and python-ideas, so I’d like to inform you of it. This change was made to PEP 1 and PEP 12. PEPs must have a Post-History header which records the dates at which the PEP is posted to mailing lists, in order

[Python-Dev] PEP Post-History (was Re: PEP 561: Distributing and Packaging Type Information)

On Oct 27, 2017, at 00:12, Guido van Rossum wrote: > > Heh, you're right that was the reasoning. But I think python-list is much > less valuable than python-ideas for PEP authors. So let's change it. Sounds good. I just want to make sure we keep python-dev in the loop. This

Re: [Python-Dev] Migrate python-dev to Mailman 3?

On Oct 26, 2017, at 10:01, Donald Stufft wrote: > Pipermail is *horrible* Pipermail also has a fatal flaw, and we have been hit by it several times in our past. It’s fundamental to Pipermail’s design and can’t be fixed. Fortunately, HyperKitty was designed and implemented

Re: [Python-Dev] Migrate python-dev to Mailman 3?

On Oct 26, 2017, at 06:15, Victor Stinner wrote: > I don't think that Mailman 3 gives the choice of the UI for archives. Technically, it does. Mailman 3 has a pluggable architecture and supports multiple archives enabled site-wide and opt-in by individual lists.

Re: [Python-Dev] PEP 561: Distributing and Packaging Type Information

On Oct 26, 2017, at 20:03, Guido van Rossum wrote: > > I think python-ideas does count here. Many PEPs evolve mostly there. True, but there was some discussion of this way back when. The way I remember it was that, while there are many outlets to discuss PEPs (including

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

On Oct 12, 2017, at 10:46, Guido van Rossum wrote: > > I am still firmly convinced that @dataclass is the right name for the > decorator (and `dataclasses` for the module). Darn, and I was going to suggest they be called EricTheHalfABees, with enums being renamed to

Re: [Python-Dev] PEP 553; the interaction between $PYTHONBREAKPOINT and -E

> I don't know what is the best option, but I dislike adding two > options, PYTHONBREAKPOINT and -X nobreakpoint, for the same features. > I would become complicated to know which option has the priority. Just to close the loop, I’ve landed the PEP 553 PR treating PYTHONBREAKPOINT the same as

Re: [Python-Dev] Intention to accept PEP 552 soon (deterministic pyc files)

On Oct 4, 2017, at 13:53, Benjamin Peterson wrote: > It might be helpful to enumerate the usecases for such an API. Perhaps a > narrow, specialized API could satisfy most needs in a supportable way. Currently `python -m dis thing.py` compiles the source then disassembles

Re: [Python-Dev] PEP 553; the interaction between $PYTHONBREAKPOINT and -E

On Oct 4, 2017, at 21:52, Nick Coghlan wrote: > >> Unfortunately we probably won’t really get a good answer in practice until >> Python 3.7 is released, so maybe I just choose one and document that the >> behavior of PYTHONBREAKPOINT under -E is provision for now. If

Re: [Python-Dev] PEP 553

On Oct 4, 2017, at 20:22, Yarko Tymciurak wrote: > I've recently started using a simple conditional breakpoint in ipython, and > wonder if - in addition to Nick Coghlan's request for the env > 'PYTHONBREAKPOINT' (boolean?), it would make sense (I _think_ so) to add a >

Re: [Python-Dev] PEP 553; the interaction between $PYTHONBREAKPOINT and -E

> """Special cases aren't special enough to break the rules.""" > > People expect -E to disable envvar-driven overrides, so just treat it > like that and don't try to second-guess the user. And of course "Although practicality beats purity.” :) So while I agree that the consistency argument

[Python-Dev] PEP 553; the interaction between $PYTHONBREAKPOINT and -E

Victor brings up a good question in his review of the PEP 553 implementation. https://github.com/python/cpython/pull/3355 https://bugs.python.org/issue31353 The question is whether $PYTHONBREAKPOINT should be ignored if -E is given? I think it makes sense for $PYTHONBREAKPOINT to be sensitive

Re: [Python-Dev] Intention to accept PEP 552 soon (deterministic pyc files)

On Oct 3, 2017, at 13:29, Benjamin Peterson wrote: > I'm not sure turning the implementation details of our internal formats > into APIs is the way to go. I still think an API in the stdlib would be useful and appropriate, but it’s not like this couldn’t be done as a 3rd

Re: [Python-Dev] Reorganize Python categories (Core, Library, ...)?

On Oct 4, 2017, at 05:52, Victor Stinner wrote: > My problem is that almost all changes go into "Library" category. When > I read long changelogs, it's sometimes hard to identify quickly the > context (ex: impacted modules) of a change. > > It's also hard to find open

Re: [Python-Dev] Intention to accept PEP 552 soon (deterministic pyc files)

Guido van Rossum wrote: > There have been no further comments. PEP 552 is now accepted. > > Congrats, Benjamin! Go ahead and send your implementation for review.Oops. > Let me try that again. While I'm very glad PEP 552 has been accepted, it occurs to me that it will now be more difficult to

Re: [Python-Dev] Make re.compile faster

On Oct 3, 2017, at 01:41, Serhiy Storchaka wrote: > > 03.10.17 06:29, INADA Naoki пише: >> More optimization can be done with implementing sre_parse and sre_compile in >> C. >> But I have no time for it in this year. > > And please don't do this! This would make

Re: [Python-Dev] Make re.compile faster

On Oct 3, 2017, at 01:35, Serhiy Storchaka wrote: > >> diff --git a/Lib/string.py b/Lib/string.py >> index b46e60c38f..fedd92246d 100644 >> --- a/Lib/string.py >> +++ b/Lib/string.py >> @@ -81,7 +81,7 @@ class Template(metaclass=_TemplateMetaclass): >> delimiter = '$'

Re: [Python-Dev] PEP 553

On Oct 2, 2017, at 18:43, Guido van Rossum wrote: > > OK. That then concludes the review of your PEP. It is now accepted! Congrats. > I am looking forward to using the backport. :-) Yay, thanks! We’ll see if I can sneak that backport past Ned. :) -Barry signature.asc

Re: [Python-Dev] PEP 553

On Oct 2, 2017, at 17:36, Guido van Rossum wrote: > I've seen your updates and it is now acceptable, except for *one* nit: in > builtins.breakpoint() the pseudo code raises RuntimeError if > sys.breakpointhook is missing or None. OTOH sys.breakpointhook() just issues > a

Re: [Python-Dev] Investigating time for `import requests`

On Oct 2, 2017, at 14:56, Brett Cannon wrote: > So Mercurial specifically is an odd duck because they already do lazy > importing (in fact they are using the lazy loading support from importlib). > In terms of all of this discussion of tweaking import to be lazy, I think the

Re: [Python-Dev] PEP 553

Thanks for the review Guido! The PEP and implementation have been updated to address your comments, but let me briefly respond here. > On Oct 2, 2017, at 00:44, Guido van Rossum wrote: > - There's a comma instead of a period at the end of the 4th bullet in the > Rationale:

Re: [Python-Dev] Investigating time for `import requests`

On Oct 1, 2017, at 22:34, Nathaniel Smith wrote: > > In principle re.compile() itself could be made lazy -- return a > regular exception object that just holds the string, and then compiles > and caches it the first time it's used. Might be tricky to do in a > backwards

Re: [Python-Dev] Python startup optimization: script vs. service

On Oct 2, 2017, at 10:48, Christian Heimes wrote: > > That approach could work, but I think that it is the wrong approach. I'd > rather keep Python optimized for long-running processes and introduce a > new mode / option to optimize for short-running scripts. What would

Re: [Python-Dev] New security-annou...@python.org mailing list

On Sep 27, 2017, at 12:24, Guido van Rossum wrote: > > Can we add redirects to the old list locations? I’m not sure we need it for security-announce given how new that list is and that we only have one message to it. I’ve forwarded this request to postmaster@ though.

Re: [Python-Dev] New security-annou...@python.org mailing list

On Sep 27, 2017, at 11:56, Jesus Cea <j...@jcea.es> wrote: > > On 21/09/17 17:30, Barry Warsaw wrote: >> https://mail.python.org/mailman/listinfo/security-announce > > "No such list security-announce". > >> https://mail.python.org/mailman/listinfo/s

[Python-Dev] New security-annou...@python.org mailing list

I’m happy to announce the availability of a new mailing list, with the mission of providing security announcements to the Python community from the Python Security Response Team (PSRT): security-annou...@python.org You can sign up in the usual Mailman way:

Re: [Python-Dev] PEP 553, v3

Barry Warsaw wrote: > 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. I've been in contact with Elizaveta Shashkova from JetBrains. She gave a great talk at Pycon 2017 which influenced my th

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