On Apr 3, 2018, at 13:08, Brett Cannon wrote:
> Are we at the PEP/language summit topic point yet in this discussion since
> Guido has said he's not interested in changing the status quo? ;) Versioning
> is like naming variables, so this thread could go on forever.
Yeah probably so. And if yo
On Apr 3, 2018, at 05:51, Paul G wrote:
> Switching to CalVer is a pretty clear sign that there is now a "rolling
> backwards compatibility window", and it allows Python to skip right over the
> mythical "Python 4" and directly to "Python 21". Additionally, since the
> version number will be t
On Mar 22, 2018, at 12:33, Oleg Broytman wrote:
>
> On Thu, Mar 22, 2018 at 12:30:02PM -0700, Barry Warsaw
> wrote:
>> Developers are mostly going to use pip, and maybe a requirements.txt,
>
> +virtual envs to avoid problems with global site-packages.
Yep, that was
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
> compatible versions are always
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 python-ideas. It’s a great
sol
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 test suite takes a long time
> 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 nitpicky about some va
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
> linefeeds instead of one be
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 not-incorrect code. I
als
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 never
> seen this idiom
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 LGTM!
-Barry
signat
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 kind of ratchet or
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 part of any band or c
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 stepped up to do it.
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 time.)
What, not the
On Jan 27, 2018, at 17:04, Guido van Rossum mailto:gu...@python.org>> 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* learned that, at least on
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 tra
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 to adjust the commit
> mess
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 button and… we’re done! Assum
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 in
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 stage of development.
A P
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
> /usr/bin have -s or -I.
-I s
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.
-Barry
signature.as
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 OpenPGP
_
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
resource
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 Guido was in favour of data
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 clas
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 to the interprete
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 the current behavio
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
Python-Dev@python.org
https://mail.pyt
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, but it IS a big step.
Th
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 mailing list
Python-Dev@p
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)
---
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 y’rs,
-Barry
signatu
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 rele
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 o
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 no sense of the rela
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 expression though
> On Nov 28, 2017, at 15:59, Paul Moore wrote:
>
> On 28 November 2017 at 20:38, Barry Warsaw wrote:
>> I had occasional to speak with someone very involved in Rust development.
>> They have a process roughly similar to our PEPs. One of the things he told
>
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 I like about Python is that I
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):
return None
re
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 `-X the-flufls-gonna-gitcha
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 develo== now you’re talki
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 REPL under -X dev? I’d ra
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 OpenPGP
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 think "But
> we've had
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 reasonable choice to me.
I’m co
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.
Instead they’d see breaka
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
__
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 we can't
> agree o
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 m
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 reviews:
content = open(s
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 import AsyncStrategy
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 you
> can stress-
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 option
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 contributions to Deb
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
deliberately left as implementa
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 environment where moving t
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 they're theoretically al
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 wants a stronger guara
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 insertion order], poi
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 3.
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 mapping that preserves
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, despite their increasing use
out
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 vs who don't
> * peop
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 above may look
> like:
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 features.
Like others here,
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 documentation for
> DeprecationW
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. So
> let's just d
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
___
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: 10.6 ms +- 0.6 ms
>
> 1
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 strongly in favor on such move.
>
> I'm torn
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 python-dev.
What
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 the
postmaster, especially
On Oct 30, 2017, at 04:00, Victor Stinner wrote:
> It's really hard to design an UI liked by everyone :-)
It’s impossible to design *anything* that’s liked by everyone :).
> I expect that Mailman 3 is more actively developed than Mailman 2. By
> the way, I hope that Mailman 3 and HyperKity supp
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 interface of Gmane too (
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 t
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 is a process chang
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 correctly so it doe
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. HyperKitty is the default arch
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 those pointed to by the
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 EricTheHalfNotBees.
-Barry
> 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 all
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 it.
It would be kind o
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 that’s
>> acceptable, the
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
> condition parameter to
> """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 make
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 to
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 party module.
-Barry
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 bugs of a specific module o
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 pars
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 maintaining the re module hard.
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 = '$'
>> idpattern = r'[
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
Description: Message s
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 RuntimeWarning when so
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
> best approach wo
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: "Breaking the idiom
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 compatibility way if it mo
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 that look like, how would
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.
-Barry
signature.asc
201 - 300 of 2704 matches
Mail list logo