[Python-Dev] Re: Typing syntax and ecosystem

On Mon, Apr 12, 2021 at 2:19 PM wrote: > April 12, 2021 4:59 PM, "Brett Cannon" wrote: > > > On Mon, Apr 12, 2021 at 3:01 AM Hugh Fisher > wrote: > > > >>> Message: 1 > >>> Date: Sun, 11 Apr 2021 13:31:12 -0700 > >>> F

[Python-Dev] Re: gzip.py: allow deterministic compression (without time stamp)

On Wed, Apr 14, 2021 at 5:00 AM Joachim Wuttke wrote: > gzip compression, using class GzipFile from gzip.py, by default > inserts a timestamp to the compressed stream. If the optional > argument `mtime` is absent or None, then the current time is used [1]. > > This makes outputs non-deterministic

[Python-Dev] Re: Typing syntax and ecosystem

On Tue, Apr 13, 2021 at 5:12 PM Hugh Fisher wrote: > On Wed, 14 Apr 2021 at 08:21, Barry Warsaw wrote: > > I wouldn’t necessarily be opposed to bundling a type checker with the > interpreter/stdlib, but I think there are some issues with it. Just off > the top of my head (there are undoubtedly

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On Tue, Apr 13, 2021 at 6:58 PM Inada Naoki wrote: > On Wed, Apr 14, 2021 at 10:44 AM Larry Hastings > wrote: > > > > > > On 4/13/21 1:52 PM, Guido van Rossum wrote: > > > > > > Because typing is, to many folks, a Really Important Concept, and it's > confusing to use the same syntax ("x: blah bl

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On Wed, Apr 14, 2021 at 12:08 PM Guido van Rossum wrote: > Let's just wait for the SC to join the discussion. I'm sure they will, > eventually. > FYI the PEP has not been sent to us via https://github.com/python/steering-council/issues as ready for pronouncement, so we have not started officiall

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On Thu, Apr 15, 2021 at 9:36 AM David Mertz wrote: > On Thu, Apr 15, 2021 at 4:55 PM Christopher Barker > wrote: > >> Presumably that's why importlib.metadata exists in the stdlib. >> > > I was so hopeful about this, but in the end... not really. I have not > used this capability before. Here

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On Thu, Apr 15, 2021 at 8:50 AM Christopher Barker wrote: > On Thu, Apr 15, 2021 at 2:40 AM Victor Stinner > wrote: > >> Paul Bryan: >> > Seems like this is something that should make its way into stdlib? >> >> In the last 10 years, the trend is more to remove anything related to >> packaging *o

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On Thu, Apr 15, 2021 at 10:53 AM Antoine Pitrou wrote: > On Thu, 15 Apr 2021 10:28:53 -0700 > Brett Cannon wrote: > > On Thu, Apr 15, 2021 at 8:50 AM Christopher Barker > > wrote: > > > > > On Thu, Apr 15, 2021 at 2:40 AM Victor Stinner > > > wrot

[Python-Dev] Re: In support of PEP 649

On Thu, Apr 15, 2021 at 12:01 PM Samuel Colvin wrote: > I've read the recent discussions > > regarding PEP 649 and PEP 563 with interest, Larry Hastings recently

[Python-Dev] Re: Keeping Python a Duck Typed Language.

On Thu, Apr 22, 2021 at 4:11 AM Paul Moore wrote: > On Thu, 22 Apr 2021 at 11:21, Paul Moore wrote: > > > > On Thu, 22 Apr 2021 at 11:06, Chris Angelico wrote: > > > > > > Someone will likely correct me if this is inaccurate, but my > > > understanding is that that's exactly what you get if you

[Python-Dev] Asking for clarifications in PEP 646 and postponing to Python 3.11

First, the SC is postponing considering accepting https://www.python.org/dev/peps/pep-0646/ any further until Python 3.11. There's unfortunately not enough time before b1 to get requested updates into the PEP, discuss the PEP again, approve it, and then review an implementation thoroughly. Second,

[Python-Dev] Re: PEP 563 and 649: The Great Compromise

On Sat., Apr. 24, 2021, 20:55 Carl Meyer, wrote: > Hi Larry, > > This is a creative option, but I am optimistic (now that the SC > decision has removed the 3.10 deadline urgency) that we can find a > path forward that is workable for everyone and doesn't require a > permanent compiler feature fla

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On Mon, Apr 26, 2021 at 9:37 AM Baptiste Carvello < devel2...@baptiste-carvello.net> wrote: > Hi, > > sorry for being late to the party, but I may not be the only one wondering… > > Le 14/04/2021 à 20:56, Barry Warsaw a écrit : > > > > I’d forgotten that this PEP was in Deferred state. I think it

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On Mon, Apr 26, 2021 at 3:25 PM Stestagg wrote: > > > On Mon, Apr 26, 2021 at 10:31 PM Brett Cannon wrote: > >> >> >> On Mon, Apr 26, 2021 at 9:37 AM Baptiste Carvello < >> devel2...@baptiste-carvello.net> wrote: >> >>> Hi, >>>

[Python-Dev] Re: Can't sync cpython main to my fork

Just today, GitHub launched a new feature to sync a branch with upstream via the web UI. https://github.blog/changelog/2021-05-06-sync-an-out-of-date-branch-of-a-fork-from-the-web On Thu., May 6, 2021, 15:16 Ethan Furman, wrote: > On 5/6/21 7:14 AM, Jelle Zijlstra wrote: > > > Maybe others hav

[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

On Fri, May 7, 2021 at 7:31 PM Pablo Galindo Salgado wrote: > Although we were originally not sympathetic with it, we may need to offer > an opt-out mechanism for those users that care about the impact of the > overhead of the new data in pyc files > and in in-memory code objectsas was suggested

[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

On Sat, May 8, 2021 at 2:59 PM Gregory P. Smith wrote: > > > On Sat, May 8, 2021 at 2:09 PM Pablo Galindo Salgado > wrote: > >> > Why not put in it -O instead? Then -O means lose asserts and lose >> fine-grained tracebacks, while -OO continues to also >> strip out doc strings. >> >> What if som

[Python-Dev] Re: python-iterators mailing list on SourceForge

On Fri, May 21, 2021 at 9:25 AM Julien Palard via Python-Dev < python-dev@python.org> wrote: > Le 5/11/21 à 8:39 PM, Guido van Rossum a écrit : > > I doubt that anyone has the keys to the python project on sourceforge > > any more... :-( We've abandoned that platform nearly two decades ago. > > T

[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

On Thu, May 13, 2021 at 1:38 AM Mark Shannon wrote: > Hi Terry, > > On 13/05/2021 8:20 am, Terry Reedy wrote: > > On 5/12/2021 1:40 PM, Mark Shannon wrote: > > > >> This is an informational PEP about a key part of our plan to improve > >> CPython performance for 3.11 and beyond. > > > > What is t

[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

On Tue., May 25, 2021, 12:58 Guido van Rossum, wrote: > On Tue, May 25, 2021 at 12:34 PM Brett Cannon wrote: > >> >> I personally think it should be a Standards Track PEP. This PEP isn't >> documenting some detail like PEP 13 or some release schedule, but is >&g

[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

On Wed, May 26, 2021 at 4:23 AM Mark Shannon wrote: > Hi Brett, > > On 26/05/2021 3:56 am, Brett Cannon wrote: > > > > > > On Tue., May 25, 2021, 12:58 Guido van Rossum, > <mailto:gu...@python.org>> wrote: > > > > On Tue, May 25, 2021 at 12

[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

these bigger projects becomes more normal. On Wed, May 26, 2021 at 1:00 PM Brett Cannon wrote: > > > On Wed, May 26, 2021 at 4:23 AM Mark Shannon wrote: > >> Hi Brett, >> >> On 26/05/2021 3:56 am, Brett Cannon wrote: >> > >> > >> &

[Python-Dev] Re: change of behaviour for '.' in sys.path between 3.10.0a7 and 3.10.0b1

On Sat., Jun. 5, 2021, 07:38 Robin Becker, wrote: > On 04/06/2021 19:29, Steve Dower wrote: > ... > > > > While we were investigating the reliably broken behaviour, we figured > that related behaviour was > > *unreliably* broken on all platforms. > > > > Specifically, if you imported a mo

[Python-Dev] Re: Roundup to GitHub Issues migration

On Mon, Jun 21, 2021 at 4:09 PM Glenn Linderman wrote: > On 6/21/2021 2:31 PM, Christopher Barker wrote: > > > By contrast, requiring a github account for reporting bugs also makes >> python an unwelcoming place for non-developers in general. Github is a >> developers' social network, "mere" user

[Python-Dev] Re: Roundup to GitHub Issues migration

On Tue., Jun. 22, 2021, 14:50 Glenn Linderman, wrote: > On 6/22/2021 12:52 PM, Brett Cannon wrote: > > > > On Mon, Jun 21, 2021 at 4:09 PM Glenn Linderman > wrote: > >> On 6/21/2021 2:31 PM, Christopher Barker wrote: >> >> >> By contrast, requiring a

[Python-Dev] Re: Is the Python review process flawed?

On Thu, Jul 1, 2021 at 4:54 PM wrote: > Okay so I just code a little bit and I used the multiprocessing module but > my code didn't work and I found the solution on Stack Overflow and it > turned out to be not my mistake (which has never happened before I think). > Instead I found out it's a bug

[Python-Dev] Re: Python3 OSF/1 support?

On Wed, Jul 14, 2021 at 9:36 AM Chris Johns wrote: > As someone who has ported Python 3 to another "less commonly used" > system (RISC OS) I just do semi-regular updates rather than trying to > keep it it totally up to date with "main". > > I have some vague recollection of there being talk about

[Python-Dev] Re: importing does not dispatch to __builtins__.__getitem__ to lookup __import__

On Wed, Jul 14, 2021 at 10:17 AM Patrick Reader wrote: > Hi there, > > I've noticed that, when a frame's __builtins__ is a subclass of dict with > an overridden __getitem__ method, this overriden method is not used by the > IMPORT_NAME instruction to lookup __import__ in the dictionary; it uses t

[Python-Dev] Re: Repealing PEP 509 (Add a private version to dict)

On Thu, Jul 29, 2021 at 3:47 AM Mark Shannon wrote: > Hi everyone, > > I would like to repeal PEP 509. We don't really have a process for > repealing a PEP. Presumably I would just write another PEP. > Yeah, it's probably a new PEP explaining why the first PEP turned out to not work out since it

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

On Mon, Aug 9, 2021 at 8:31 AM Eric V. Smith wrote: > I'd like to revive the discussion of PEP 649 > [https://www.python.org/dev/peps/pep-0649/] that started shortly before > development of 3.10 features was closed. This is Larry's PEP to defer > evaluation of __annotations__ until it's actually

[Python-Dev] Should we try to get a complete draft of What's New by b1?

Not to specifically pick on Eric V. Smith, but yesterday a co-worker came to me asking about `KW_ONLY` for dataclasses and wanting to provide feedback ( https://docs.python.org/3.10/library/dataclasses.html#dataclasses.KW_ONLY). I said we had reached RC and so it was pretty much too late; the alpha

[Python-Dev] Re: Should we try to get a complete draft of What's New by b1?

org you will see that we already have the docs for 3.10 and 3.11 available. I don't know if they are updated per release right now or per commit. -Brett > > On Thu, Aug 12, 2021, 3:02 AM Serhiy Storchaka > wrote: > >> 11.08.21 21:35, Brett Cannon пише: >> > So

[Python-Dev] Re: PEP 467 feedback from the Steering Council

Barry Warsaw wrote: > On Aug 4, 2021, at 07:31, Victor Stinner vstin...@python.org wrote: > > On Tue, Aug 3, 2021 at 7:54 PM Ethan Furman et...@stoneleaf.us wrote: > > I would rather keep `bchr` and lose the `.fromint()` methods. > > I would prefer to only have a bytes.byte(65) method, no bchr() >

[Python-Dev] Re: PEP 558, the simplest thing I could come up with

On Sat, Aug 14, 2021 at 8:01 PM Nick Coghlan wrote: > Bringing the public record up to date with a brief off-list discussion > between Mark, Nathaniel and I: > > * Mark hasn't convinced me that getting rid of the frame value cache > entirely for optimised frames is a good idea, so he's going to w

[Python-Dev] python-dev thread w/ Marco Sulla

https://mail.python.org/archives/list/python-dev@python.org/thread/JRFJ4QH7TR35HFRQWOYPPCGOYRFAXK24/ I can't be objective with Marco as I believe we have recorded issues with him previously (as with Steven if you take Marco's initial side with this). The thing that pushed me over the edge to repo

[Python-Dev] Re: Problems with dict subclassing performance

On Sun, Aug 15, 2021 at 2:55 PM Marco Sulla wrote: > On Sun, 15 Aug 2021 at 23:33, Tim Peters > wrote:ople have said now, including me, they had no idea what > > you meant.by "I pretend your immediate excuses". It's not a complaint > > that it's expressed inelegantly, but that they can't make _a

[Python-Dev] Re: python-dev thread w/ Marco Sulla

On Mon, Aug 16, 2021 at 1:37 PM Jonathan Goble wrote: > On Mon, Aug 16, 2021 at 4:04 PM Nathan C. Fox > wrote: > >> Yes, it was intended to go to python-dev, even though it's not about >> Python development. It's part of a discussion about a pretty hostile and >> off-topic thread that has unfold

[Python-Dev] Re: Problems with dict subclassing performance

polemic started. Since, I repeat, I have more than 13k reputation on > SO, and since the question had about 20 votes without dirty tricks, as > Steven subtly insinuates, all of this makes me laugh. Do your worst, > you all little men. As a Mister No One, I will be **PROUD** to be > bann

[Python-Dev] Re: Should PEP 8 be updated for Python 3 only?

On Wed, Aug 25, 2021 at 10:32 AM Mike Miller wrote: > > How about moving Python 2 notes into a section at the bottom? > I don't think that's useful. PEP 8 is still meant for the stdlib which is obviously not using Python 2, so it just becomes baggage. Plus if people want to refer to the old vers

[Python-Dev] My apologies to the list

I just wanted to apologize for any angst or noise my replies to Marco caused folks. I should have known that correcting Marco on how to address me would have triggered an outsized reply (the real intent of that overall email was to communicate the process of banning someone to the rest of the list

[Python-Dev] Re: [Steering-council] Re: A ban from Core Developer spaces.

On Thu, Aug 26, 2021 at 12:10 AM Simon Cross wrote: > Hi Thomas, > > Could I ask a bit about the thinking behind extending the ban to a > year? It wouldn't view it as an extension as much as Ethan took immediate action while the SC was simultaneously working on what to do about the situation. S

[Python-Dev] Re: Notes on PEP 8

On Wed, Aug 25, 2021 at 10:38 PM Christopher Barker wrote: > As I was working on removing Python 2 references from PEP 8 (PR: > https://github.com/python/peps/pull/2059), I tried to avoid any other > copy-editing. > > However, I noted a few things that maybe could use some attention: > > stdlib o

[Python-Dev] Discrepancy between what aiter() and `async for` requires on purpose?

If you look at https://github.com/python/cpython/blob/b11a951f16f0603d98de24fee5c023df83ea552c/Python/ceval.c#L2409-L2451 you will see that `async for` requires that the iterator returned from `__aiter__` define `__anext__`. But if you look at aiter() which uses PyObject_GetAiter() from https://git

[Python-Dev] Re: Discrepancy between what aiter() and `async for` requires on purpose?

On Sun, Aug 29, 2021 at 2:01 PM Serhiy Storchaka wrote: > 29.08.21 23:16, Brett Cannon пише: > > If you look at > > > https://github.com/python/cpython/blob/b11a951f16f0603d98de24fee5c023df83ea552c/Python/ceval.c#L2409-L2451 > > < > https://

[Python-Dev] Re: PEP-535 (Rich comparison chaining) Discussion?

Link to the PEP: https://www.python.org/dev/peps/pep-0535/ On Tue, Aug 31, 2021 at 8:52 AM Angus Hollands wrote: > Hi all, > > PEP 535 was deferred until Python 3.8. I would like to discuss the PEP > given that some time has passed, and I _personally_ would benefit from its > acceptance. > > > #

[Python-Dev] Re: Discrepancy between what aiter() and `async for` requires on purpose?

On Thu, Sep 2, 2021 at 7:43 PM Yury Selivanov wrote: > Comments inlined: > > On Thu, Sep 2, 2021 at 6:23 PM Guido van Rossum wrote: > >> First of all, we should ping Yury, who implemented `async for` about 6 >> years ago (see PEP 492), and Joshua Bronson, who implemented aiter() and >> anext() a

[Python-Dev] Re: Discrepancy between what aiter() and `async for` requires on purpose?

On Wed, Sep 8, 2021 at 12:49 PM Yury Selivanov wrote: > We have already merged it, the fix is part of the rc2. > Thanks! (If we were on Discourse I would have left a ♥ instead 😃) > > yury > > > On Wed, Sep 8 2021 at 12:48 PM, Brett Cannon wrote: > >> On Th

[Python-Dev] Re: A better way to freeze modules

On Sat, Sep 11, 2021 at 7:08 PM Gregory Szorc wrote: > Thanks for all the replies, everyone! I'll reply to a few comments > individually. But I first wanted to address the common theme around > zipimport. > > First, one idea that nobody mentioned (and came to me after reading the > replies) was t

[Python-Dev] Should the definition of an "(async) iterator" include __iter__?

Over in https://github.com/python/typeshed/issues/6030 I have managed to kick up a discussion over what exactly an "iterator" is. If you look at https://docs.python.org/3/library/functions.html#iter you will see the docs say it "Return[s] an iterator

[Python-Dev] Re: Should the definition of an "(async) iterator" include __iter__?

On Wed, Sep 15, 2021 at 4:06 PM Guido van Rossum wrote: > [SNIP] > Reminder about how for-loops work: > > This: > > for x in seq: > > > translates (roughly) to this: > > _it = iter(seq) > while True: > try: > x = next(_it) > except StopIteration: > break > > And

[Python-Dev] Discussion about how to manage additions/removals to the stdlib

https://discuss.python.org/t/how-do-we-want-to-manage-additions-removals-to-the-stdlib/10681 This comes from my language summit talk on the stdlib to help clarify some things about how we manage the stdlib from the perspective of additions/deletions. FYI I will be *muting this email thread immedi

[Python-Dev] Re: Should the definition of an "(async) iterator" include __iter__?

um wrote: > >> My view of this is: >> >> A. It's not an iterator if it doesn't define `__next__`. >> >> B. It is strongly recommended that iterators also define `__iter__`. >> >> In "standards" language, I think (A) is MUST and (B) is

[Python-Dev] Re: f-strings in the grammar

On Mon, Sep 20, 2021 at 8:58 AM Thomas Grainger wrote: > I don't think the python syntax should be beholden to syntax highlighting > tools, eventually some syntax feature that PEG enables will require every > parser or highlighter to switch to a similar or more powerful parse tool > But that's n

[Python-Dev] Re: Worried about Python release schedule and lack of stable C-API

On Sun, Sep 26, 2021 at 3:51 AM Phil Thompson via Python-Dev < python-dev@python.org> wrote: > On 26/09/2021 05:21, Steven D'Aprano wrote: > > [snip] > > > These are not rhetorical questions, I genuinely do not know. I *think* > > that there was an attempt to make a stable C API back in 3.2 days

[Python-Dev] Re: The Default for python -X frozen_modules.

On Mon, Sep 27, 2021 at 9:54 AM Eric Snow wrote: > We've frozen most of the stdlib modules imported during "python -c > pass" [1][2], to make startup a bit faster. Import of those modules > is controlled by "-X frozen_modules=[on|off]". Currently it defaults > to "off" but we'd like to default

Re: [Python-Dev] cffi in stdlib

On Tue, Feb 26, 2013 at 2:12 PM, Guido van Rossum wrote: > Generally speaking, deferring something to Python 4 means "never". > Does that mean your aversion to double digit version numbers (i.e. 3.10) is gone or you expect to freeze Python in carbonite by then? -Brett > > On Tue, Feb 26, 2013

Re: [Python-Dev] cffi in stdlib

On Wed, Feb 27, 2013 at 1:28 PM, Paul Moore wrote: > 27 February 2013 18:24, Paul Moore wrote: > > On 27 February 2013 11:53, Maciej Fijalkowski wrote: > >> I think it means you can't use the ABI version and specify the calling > >> convention. It's a reasonable bug report (the calling convent

Re: [Python-Dev] Python Language Summit at PyCon: Agenda

On Wed, Feb 27, 2013 at 2:01 PM, fwierzbi...@gmail.com < fwierzbi...@gmail.com> wrote: > On Wed, Feb 27, 2013 at 8:51 AM, Michael Foord > wrote: > > If you have other items you'd like to discuss please let me know and I > can add them to the agenda. > > I'd like to discuss merging Jython's standa

Re: [Python-Dev] Python Language Summit at PyCon: Agenda

On Thu, Feb 28, 2013 at 6:34 AM, Michael Foord wrote: > > On 28 Feb 2013, at 07:36, Georg Brandl wrote: > > > Am 27.02.2013 17:51, schrieb Michael Foord: > >> Hello all, > >> > >> PyCon, and the Python Language Summit, is nearly upon us. We have a > good number of people confirmed to attend. If y

Re: [Python-Dev] Python Language Summit at PyCon: Agenda

On Thu, Feb 28, 2013 at 8:53 AM, Benjamin Peterson wrote: > 2013/2/28 Brett Cannon : > > > > > > > > On Thu, Feb 28, 2013 at 6:34 AM, Michael Foord < > fuzzy...@voidspace.org.uk> > > wrote: > >> > >> > >> On 28 Feb 2013, at

Re: [Python-Dev] Merging Jython code into standard Lib [was Re: Python Language Summit at PyCon: Agenda]

On Thu, Feb 28, 2013 at 3:17 PM, fwierzbi...@gmail.com < fwierzbi...@gmail.com> wrote: > On Thu, Feb 28, 2013 at 12:00 PM, Antoine Pitrou > wrote: > > IMHO, we should remove the plat-* directories, they are completely > > unmaintained, undocumented, and serve no useful purpose. > Oh I didn't know

Re: [Python-Dev] Python Language Summit at PyCon: Agenda

On Fri, Mar 1, 2013 at 4:41 AM, Stefan Behnel wrote: > Michael Foord, 27.02.2013 17:51: > > PyCon, and the Python Language Summit, is nearly upon us. We have a good > number of people confirmed to attend. If you are intending to come to the > language summit but haven't let me know please do so.

[Python-Dev] Planning on removing cache invalidation for file finders

As of right now, importlib keeps a cache of what is in a directory for its file finder instances. It uses mtime on the directory to try and detect when it has changed to know when to refresh the cache. But thanks to mtime granularities of up to a second, it is only a heuristic that isn't totally re

Re: [Python-Dev] Merging Jython code into standard Lib [was Re: Python Language Summit at PyCon: Agenda]

On Sat, Mar 2, 2013 at 10:28 AM, Antoine Pitrou wrote: > On Sun, 3 Mar 2013 01:17:35 +1000 > Nick Coghlan wrote: > > > > I'd go further and say we *should* move to that solution. > > > > Here's an interesting thought: for pure C modules without a Python > > implementation, we can migrate to this

Re: [Python-Dev] Planning on removing cache invalidation for file finders

On Sat, Mar 2, 2013 at 10:36 AM, Nick Coghlan wrote: > On Sat, Mar 2, 2013 at 12:31 PM, Brett Cannon wrote: > > As of right now, importlib keeps a cache of what is in a directory for > its > > file finder instances. It uses mtime on the directory to try and detect > when

Re: [Python-Dev] Planning on removing cache invalidation for file finders

On Sat, Mar 2, 2013 at 12:24 PM, Nick Coghlan wrote: > On Sun, Mar 3, 2013 at 2:16 AM, Brett Cannon wrote: > > On Sat, Mar 2, 2013 at 10:36 AM, Nick Coghlan > wrote: > >> I think you should keep it. A long running service that periodically > >> scans the importe

Re: [Python-Dev] Planning on removing cache invalidation for file finders

On Sat, Mar 2, 2013 at 8:16 PM, Antoine Pitrou wrote: > On Sat, 2 Mar 2013 11:16:28 -0500 > Brett Cannon wrote: > > > In addition, it may be appropriate for importlib to offer a > > > "write_module" method that accepts (module name, target path, > > >

Re: [Python-Dev] Planning on removing cache invalidation for file finders

On Sun, Mar 3, 2013 at 6:29 AM, Antoine Pitrou wrote: > On Sat, 2 Mar 2013 18:38:15 -0500 > Brett Cannon wrote: > > > > > > You can deprecate the heuristic if you want (and can figure out how), > > > but a definite -1 on removing it without at least the u

Re: [Python-Dev] Planning on removing cache invalidation for file finders

On Sun, Mar 3, 2013 at 12:08 PM, Brett Cannon wrote: > > > > On Sat, Mar 2, 2013 at 8:16 PM, Antoine Pitrou wrote: > >> On Sat, 2 Mar 2013 11:16:28 -0500 >> Brett Cannon wrote: >> > > In addition, it may be appropriate for importlib to offer a >> &

Re: [Python-Dev] Introducing Electronic Contributor Agreements

On Mon, Mar 4, 2013 at 11:30 AM, Brian Curtin wrote: > The full announcement is at > http://blog.python.org/2013/03/introducing-electronic-contributor.html, > but a summary follows. > > We've now moved to an electronic Contributor License Agreement form at > http://www.python.org/psf/contrib/cont

Re: [Python-Dev] Python Language Summit at PyCon: Agenda

On Mon, Mar 4, 2013 at 11:29 AM, Barry Warsaw wrote: > On Mar 04, 2013, at 07:26 PM, Robert Collins wrote: > > >It is of course possible for subunit and related tools to run their > >own implementation, but it seems ideal to me to have a common API > >which regular unittest, nose, py.test and oth

Re: [Python-Dev] Python Language Summit at PyCon: Agenda

On Mon, Mar 4, 2013 at 11:44 AM, David Cournapeau wrote: > On Mon, Mar 4, 2013 at 4:34 PM, Brett Cannon wrote: > > > > > > > > On Mon, Mar 4, 2013 at 11:29 AM, Barry Warsaw wrote: > >> > >> On Mar 04, 2013, at 07:26 PM, Robert Collins wrote: > &

Re: [Python-Dev] Python Language Summit at PyCon: Agenda

On Mon, Mar 4, 2013 at 3:45 PM, Barry Warsaw wrote: > On Mar 04, 2013, at 03:40 PM, Daniel Holth wrote: > > >On Mon, Mar 4, 2013 at 3:14 PM, Barry Warsaw wrote: > >> On Mar 04, 2013, at 03:02 PM, Daniel Holth wrote: > >> > >>>setup.py's setup(test_suite="x")... not sure if this is a distutils or

Re: [Python-Dev] Introducing Electronic Contributor Agreements

On Mon, Mar 4, 2013 at 4:33 PM, Mark Lawrence wrote: > On 04/03/2013 20:46, Terry Reedy wrote: > >> On 3/4/2013 11:36 AM, Brett Cannon wrote: >> >>> >>> >>> >>> On Mon, Mar 4, 2013 at 11:30 AM, Brian Curtin >> <mailto:br...@python.or

Re: [Python-Dev] Introducing Electronic Contributor Agreements

On Tue, Mar 5, 2013 at 11:48 AM, Baptiste Carvello < de...@baptiste-carvello.net> wrote: > Le 05/03/2013 04:13, Stephen J. Turnbull a écrit : > > Mark Lawrence writes: > > > > > People already use the bug tracker as an excuse not to contribute, > > > wouldn't this requirement make the situation

Re: [Python-Dev] Introducing Electronic Contributor Agreements

On Wed, Mar 6, 2013 at 3:06 PM, Steven D'Aprano wrote: > On 05/03/13 09:08, Brett Cannon wrote: > > Depends on your paranoia. If you're worried about accidentally lifting IP >> merely by reading someone's source code, then you wouldn't want to touch >> c

Re: [Python-Dev] [Python-checkins] cpython (2.7): #16004: Add `make touch`.

On Mon, Mar 11, 2013 at 9:22 AM, Brett Cannon wrote: > Should this also touch Python/importlib.h? > > nm, noticed this was added on 2.7 and not default. > > On Mon, Mar 11, 2013 at 3:14 AM, ezio.melotti > wrote: > >> http://hg.python.org/cpython/rev/da3f477

Re: [Python-Dev] [Python-checkins] cpython (2.7): #16004: Add `make touch`.

Should this also touch Python/importlib.h? On Mon, Mar 11, 2013 at 3:14 AM, ezio.melotti wrote: > http://hg.python.org/cpython/rev/da3f4774b939 > changeset: 82600:da3f4774b939 > branch: 2.7 > parent: 82593:3e14aafeca04 > user:Ezio Melotti > date:Mon Mar 11 09:14:09 2

Re: [Python-Dev] IDLE in the stdlib

On Wed, Mar 20, 2013 at 3:51 PM, Xavier Morel wrote: > On 2013-03-20, at 20:38 , Barry Warsaw wrote: > > > On Mar 20, 2013, at 12:31 PM, Guido van Rossum wrote: > > > >> Agreed that the "sync into stdlib" think should not happen, or should at > >> best be a temporary measure until we can remove id

Re: [Python-Dev] Writing importers and path hooks

On Wed, Mar 27, 2013 at 6:59 PM, Paul Moore wrote: > On 27 March 2013 21:19, Bradley M. Froehle wrote: > > I implemented just such a path hook zipimporter plus the magic > required > > for C extensions --- as a challenge to myself to learn more about the > Python > > import mechanisms. > >

Re: [Python-Dev] Writing importers and path hooks

On Thu, Mar 28, 2013 at 11:38 AM, Paul Moore wrote: > On 28 March 2013 13:42, Brett Cannon wrote: > >> importer, as I wanted to try a proof of concept importer based on the > >> new importlib stuff (which is intended to make writing custom > >> importers easier),

Re: [Python-Dev] Safely importing zip files with C extensions

On Thu, Mar 28, 2013 at 10:44 AM, Thomas Heller wrote: > Am 27.03.2013 20:38, schrieb Vinay Sajip: > > This quote is here to stop GMane complaining that I'm top-posting. Ignore. >>> >> >> I've already posted this to distutils-sig, but thought that it might be of >> interest to readers here as it

Re: [Python-Dev] Writing importers and path hooks

On Thu, Mar 28, 2013 at 12:33 PM, Paul Moore wrote: > On 28 March 2013 16:08, Brett Cannon wrote: > > You only need SourceLoader since you are dealing with Python source. You > > don't need FileLoader since you are not reading from disk but an > in-memory > > z

Re: [Python-Dev] [Python-checkins] cpython (2.7): Add an itertools recipe showing how to use t.__copy__().

"Upcomping" -> "upcoming" On Mar 31, 2013 2:38 AM, "raymond.hettinger" wrote: > http://hg.python.org/cpython/rev/1026b1d47f30 > changeset: 83037:1026b1d47f30 > branch: 2.7 > parent: 83034:e044d22d2f61 > user:Raymond Hettinger > date:Sat Mar 30 23:37:57 2013 -0700 > su

Re: [Python-Dev] relative import circular problem

On Mon, Apr 1, 2013 at 4:20 PM, Kristján Valur Jónsson < krist...@ccpgames.com> wrote: > I just ran into the issue described in > http://stackoverflow.com/questions/6351805/cyclic-module-dependencies-and-relative-imports-in-python > . > > This is unfortunate, because we have been trying to move t

Re: [Python-Dev] PEP 4XX: pyzaa "Improving Python ZIP Application Support"

On Tue, Apr 2, 2013 at 1:20 PM, Steve Dower wrote: > > python -m pyzaa pack [-o path/name] [-m module.submodule:callable] [-c] > [-w] [-p interpreter] directory: > > > >ZIP the contents of directory as directory.pyz or [-w] > directory.pyzw. Adds the executable flag to the archive. > > > > ...

Re: [Python-Dev] [Announcement] New mailing list for code quality tools including Flake8, Pyflakes and Pep8

On Thu, Apr 4, 2013 at 10:42 AM, Antoine Pitrou wrote: > Le Thu, 4 Apr 2013 06:57:14 +0200, > Charles-François Natali a écrit : > > > Are you planning to cover the code quality of the interpreter itself > > > too? I've been recently reading through the cert.org secure coding > > > practice recom

Re: [Python-Dev] relative import circular problem

On Thu, Apr 4, 2013 at 5:00 PM, PJ Eby wrote: > On Thu, Apr 4, 2013 at 4:42 PM, Guido van Rossum wrote: > > I do think it would be fine if "from a import b" returned the > > attribute 'b' of module 'a' if it exists, and otherwise look for > > module 'a.b' in sys.modules. > > Technically, it alre

Re: [Python-Dev] relative import circular problem

On Apr 4, 2013 6:47 PM, "Guido van Rossum" wrote: > > +1 on Brett and PJE just doing this. I'll file a bug when I get home. -brett > > On Thu, Apr 4, 2013 at 3:38 PM, Brett Cannon wrote: > > > > > > > > On Thu, Apr 4, 2013 at 5:00 PM, PJ E

Re: [Python-Dev] relative import circular problem

http://bugs.python.org/issue17636 On Thu, Apr 4, 2013 at 8:03 PM, Brett Cannon wrote: > > On Apr 4, 2013 6:47 PM, "Guido van Rossum" wrote: > > > > +1 on Brett and PJE just doing this. > > I'll file a bug when I get home. > > -brett > >

Re: [Python-Dev] The end of 2.7

On Sat, Apr 6, 2013 at 5:02 PM, Benjamin Peterson wrote: > Per my last message, 2.7.4 has at long last been released. I apologize > for the long interval between 2.7.3 and 2.7.4. To create more > determinism in the future, I will be soon updating PEP 373 with > approximate dates of future 2.7 bugf

Re: [Python-Dev] Deciding against the CLA (was: Introducing Electronic Contributor Agreements)

On Sat, Apr 13, 2013 at 6:30 AM, Ben Finney wrote: > "Stephen J. Turnbull" writes: > >> Mark Lawrence writes: >> >> > People already use the bug tracker as an excuse not to contribute, >> > wouldn't this requirement make the situation worse? >> >> A failure to sign the CLA is already a decision

[Python-Dev] A decade as a core dev

Today marks my 10 year anniversary as a core developer on Python. I wrote a blog post to mark the occasion (http://sayspy.blogspot.ca/2013/04/a-decade-of-commits.html), but I wanted to personally thank python-dev for the past decade (and whatever comes in the future). All of you taught me how to re

Re: [Python-Dev] A decade as a core dev

be able to pronounce your name properly. =) Seriously though, yes, I've learned tons about all sorts of things during my time here. -Brett > > On Thu, Apr 18, 2013 at 8:02 AM, Brett Cannon wrote: >> Today marks my 10 year anniversary as a core developer on Python. I >> wrot

Re: [Python-Dev] A decade as a core dev

On Thu, Apr 18, 2013 at 2:21 PM, Todd V Rovito wrote: > On Apr 18, 2013, at 11:02 AM, Brett Cannon wrote: > >> Today marks my 10 year anniversary as a core developer on Python. I >> wrote a blog post to mark the occasion >> (http://sayspy.blogspot.ca/2013/04/a-decade

Re: [Python-Dev] [Python-checkins] cpython (3.3): Issue #17357: Use more stern wording for

: 83517:4b4ed1e11fd0 > user: Brett Cannon > date:Sat Apr 27 23:20:32 2013 -0400 > summary: > Issue #17357: Use more stern wording for > importlib.invalidate_caches(). > > files: > Doc/library/importlib.rst | 10 +- > 1 files changed, 5 insertion

Re: [Python-Dev] [Python-checkins] cpython: #17115, 17116: Have modules initialize the __package__ and __loader__

FYI, I'm aware this broke some buildbots and will have a look today to figure out why. On Sat, May 4, 2013 at 1:57 PM, brett.cannon wrote: > http://hg.python.org/cpython/rev/e39a8f8ceb9f > changeset: 83607:e39a8f8ceb9f > user: Brett Cannon > date:Sat May 04 13

Re: [Python-Dev] Mysterious Python pyc file corruption problems

On Wed, May 15, 2013 at 4:58 PM, Barry Warsaw wrote: > I am looking into a particularly vexing Python problem on Ubuntu that > manifests in several different ways. I think the problem is the same one > described in http://bugs.python.org/issue13146 and I sent a message on the > subject to the ubu

Re: [Python-Dev] Mysterious Python pyc file corruption problems

On Thu, May 16, 2013 at 5:19 PM, Guido van Rossum wrote: > This reminds me of the following bug, which can happen when two > processes are both writing the .pyc file and a third is reading it. > First some background. > > When writing a .pyc file, we use the following strategy: > - open the file

Re: [Python-Dev] Mysterious Python pyc file corruption problems

> Sent from Mailbox > > > On Thu, May 16, 2013 at 2:36 PM, Brett Cannon wrote: >> >> On Thu, May 16, 2013 at 5:19 PM, Guido van Rossum >> wrote: >> > This reminds me of the following bug, which can happen when two >> > processes are both writing th

<    5   6   7   8   9   10   11   12   13   14   >