[Python-Dev] Re: Tottime column for cprofile output does not add up

On 3/10/2021 7:16 AM, Jonathan Frawley wrote: I am using cprofile and PStats to try and figure out where bottlenecks are in a program. When I sum up all of the times in the "tottime" column, it only comes to 57% of the total runtime. Is this due to rounding of times or some other issue? pyde

[Python-Dev] Re: aiter/anext review request

On 3/19/2021 6:11 PM, Joshua Bronson wrote: Discussion here so far is converging on resurrecting my original PR from 2018 adding these to operator. I prefer this too. -- Terry Jan Reedy ___ Python-Dev mailing list -- python-dev@python.org To unsubsc

[Python-Dev] Re: Where and how can I contribute?

On 3/26/2021 6:29 AM, Marco Sulla wrote: I would contribute to the project in my spare time. Can someone point me to some easy task? I know C and the Python C API a little. Review existing PRs. In some cases (ask), convert existing patches posted on bpo issues to PRs. -- Terry Jan Reedy __

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

On 3/26/2021 7:19 PM, Guido van Rossum wrote: Everyone, Given the resounding silence I'm inclined to submit this to the Steering Council. While I'm technically a co-author, Irit has done almost all the work, and she's done a great job. If there are no further issues I'll send this SC-wards on

[Python-Dev] Re: Where and how can I contribute?

On 3/27/2021 4:06 AM, Serhiy Storchaka wrote: 26.03.21 20:37, Terry Reedy пише: On 3/26/2021 6:29 AM, Marco Sulla wrote: I would contribute to the project in my spare time. Can someone point me to some easy task? I know C and the Python C API a little. Review existing PRs.  In some cases

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

On 4/1/2021 9:38 PM, Guido van Rossum wrote: On Thu, Apr 1, 2021 at 2:18 PM Mark Shannon > wrote: Almost all the changes come from requiring __match_args__ to be a tuple of unique strings. The current posted PEP does not say 'unique' and I agree with Guido that

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

On 4/2/2021 12:02 AM, Guido van Rossum wrote: On Thu, Apr 1, 2021 at 8:01 PM Terry Reedy The current near-Python code does not have such a check. Again, I'm not sure what "the current near-Python code" refers to. From context it seems you are referring to the pseudo cod

[Python-Dev] Re: NOTE: Python 3.9.3 contains an unintentional ABI incompatibility leading to crashes on 32-bit systems

On 4/3/2021 7:15 PM, Miro Hrončok wrote: On 03. 04. 21 21:44, Łukasz Langa wrote: The memory layout of PyThreadState was unintentionally changed in the recent 3.9.3 bugfix release. This leads to crashes on 32-bit systems when importing binary extensions compiled for Python 3.9.0 - 3.9.2. This

[Python-Dev] Re: NOTE: Python 3.9.3 contains an unintentional ABI incompatibility leading to crashes on 32-bit systems

On 4/4/2021 9:57 AM, Łukasz Langa wrote: On 4 Apr 2021, at 11:34, Matthias Klose > wrote: I always tested the release candidates, and built them for various Linux architectures.  And I'm filing issues marked as 'released-blocker' when I see regressions introduced, it'

[Python-Dev] Re: Help to Resolve issues with Pull request 25220

On 4/7/2021 12:32 PM, Barney Gale wrote: It looks like you’ve incorporated several other changes into your commit by mistake. The PR definitely has too many changes unrelated to the issue. I recognize a few of the changes as related to recent merges. My guess that the the issue-43737 branch

[Python-Dev] Re: [EXTERNAL] PEP 647 Accepted

On 4/10/2021 1:02 PM, Guido van Rossum wrote: I propose that we just clarify this in the docs we'll write for TypeGuard. I agree. When I reviewed the PEP, my concern was not with 'TypeGuard' itself, once I understood more or less what it means, but with the explanation in the PEP. -- Terr

[Python-Dev] Re: Immutable view classes - inherit from dict or from Mapping?

On 4/12/2021 11:29 AM, Andreas R Maier wrote: I have written ... My question is, should ... The pydev list is for development of future Python versions and CPython releases. Questions about the use of, or development with, current versions and releases should be directed elsewhere, such as

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

On 4/13/2021 4:21 AM, Baptiste Carvello wrote: Le 12/04/2021 à 03:55, Larry Hastings a écrit : * in section "Interactive REPL Shell": For the sake of simplicity, in this case we forego delayed evaluation. The intention of the code + codeop modules is that people should be able to write in

[Python-Dev] Re: Making staticmethod callable, any oposite?

On 4/13/2021 9:20 PM, Inada Naoki wrote: But Mark Shannon said we shouldn't make such a change without discussing at python-dev. I don't know we *should*, but I agree that it is *ideal*. I consider this case borderline. A lot of changes get made, and must be, without pydev discussion. Then

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

On 4/14/2021 8:00 AM, Joachim Wuttke wrote: Furthermore, if policy about API changes allows, I'd suggest that `NO_TIMESTAMP` become the new default value for `mtime`. Changing defaults is a huge pain, which we mostly avoid. -- Terry Jan Reedy ___

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

On 4/15/2021 12:38 PM, Barry Warsaw wrote: On Apr 14, 2021, at 23:11, Christopher Barker wrote: You wrote the original PEP, so of course you can withdraw it (or reject it), but... Are you sure? See this discussion, I don't think it's as simple as all that. From a library maintainers poi

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

On 4/15/2021 12:35 PM, David Mertz wrote: re 2.2.1 re.__version__ was last modified 2001-10-07 by F. Lundh in bec95b9d8825b39cff46a8c645fa0eeb8409854e. What does '2.2.1' mean? Only Fredrik knows. The commit message says that he rewrote the pattern.sub and pattern.subn methods in C. That

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

On 4/17/2021 11:43 PM, Larry Hastings wrote: The heart of the debate between PEPs 563 and 649 is the question: what should an annotation be?  Should it be a string or a Python value?  It seems people who are pro-PEP 563 want it to be a string, and people who are pro-PEP 649 want it to be a

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

On 4/22/2021 9:15 AM, Paul Moore wrote: Absolutely, I see no problem with "use duck typing for this argument" being opt-in. As in x: 'duck'? or x: '!', where '!' means 'infer it!', or from typing import Infer ... x: Infer ? Ditto for -> ? -- Terry Jan Reedy __

[Python-Dev] Re: expanduser('~other') reliability and future

On 4/28/2021 1:05 PM, Guido van Rossum wrote: On UNIX-oid platforms (e.g. BSD, Linux, Mac), ~user/ should be reasonably reliable, after all the shell does it. On Windows, only ~/ can be relied upon -- the rest is "best effort". I'd be okay with deprecating ~user/ on Windows, but on UNIX-oid it

[Python-Dev] Re: On the migration from master to main

On 5/3/2021 7:45 PM, Tim Peters wrote: I'm guessing it's time to fiddle local CPython clones to account for master->main renaming now? If so, I've seen two blobs of instructions, which are very similar but not identical: Blob 1 ("origin"): """ You just need to update your local clone after the

[Python-Dev] Re: On the migration from master to main

On 5/3/2021 9:27 PM, Terry Reedy wrote: On 5/3/2021 7:45 PM, Tim Peters wrote: I'm guessing it's time to fiddle local CPython clones to account for master->main renaming now? Blob 2 ("upstream"): """ The CPython repository's default branch was re

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

On 5/10/2021 3:28 AM, M.-A. Lemburg wrote: I'm mostly thinking of tracebacks which go >10 levels deep, which is rather common in larger applications. For those tracebacks, the top entries are mostly noise you never look at when debugging. The proposal now adds another 10 extra lines to jump over

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

On 5/10/2021 6:07 AM, Steven D'Aprano wrote: On Mon, May 10, 2021 at 05:34:12AM -0400, Terry Reedy wrote: On 5/10/2021 3:28 AM, M.-A. Lemburg wrote: I'm mostly thinking of tracebacks which go >10 levels deep, which is rather common in larger applications. For those tracebacks, th

[Python-Dev] Re: Speeding up CPython

On 5/12/2021 2:50 PM, Abdur-Rahmaan Janhangeer wrote: Great news, just a tiny bit from me. I read the other day in the OpenSource report sponsored by the Ford Foundation a CPython contributor stating that we have an all time high count of Python users but an all time low number of contributors to

[Python-Dev] Re: Speeding up CPython

On 5/12/2021 5:14 PM, Antoine Pitrou wrote: On Wed, 12 May 2021 17:05:03 -0400 Terry Reedy wrote: Yet you always see it: new people not knowing where to start, highly skilled contributors drowning and intermediate contributors moving slowly I have multiple times strongly recommended that

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

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. As always, comments and suggestions are welcome. The claim that starts the Motivation section, "Python is widely acknowledged as slow.", h

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

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 the purpose of this PEP? It seems in part to be like a Standards Track PEP in that it proposes a new (revised) implementation idea

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

On 5/13/2021 4:18 AM, Mark Shannon wrote: Hi Terry, On 13/05/2021 5:32 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. As always, comments and suggestions are

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

On 5/20/2021 10:49 AM, Oscar Benjamin wrote: On Thu, 20 May 2021 at 04:58, Terry Reedy wrote: I believe the ratio for the sort of numerical computing getting bogus complaints is sometimes more like 95% of *time* in compiled C and only, say, 5% of *time* in the Python interpreter. So even if

[Python-Dev] Re: My help with yours IDLE

On 6/7/2021 12:20 PM, MatroCholo wrote: Dear Python Developers, I have found that default IDLE can't open .py files on double click After installing with the python.org Windows installer, double-clicking x.py should run x.py with the default python. It does for me. The file should be design

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

On 6/22/2021 4:00 AM, Tiziano Zito wrote: Hi, On Mon 21 Jun, 13:48 +0200, Victor Stinner wrote: The requirement for a GitHub account was well known when PEP 581 was accepted. The PEP was approved. It's now time to move on! I think it is important to notice that GitHub actively blocks user r

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

On 6/22/2021 4:40 AM, Baptiste Carvello wrote: Le 21/06/2021 à 23:31, Christopher Barker a écrit : Also: cPython is a large, complex, and mature project. I don't think many non-developers can even identify a true bug, much less write a helpful big report. [...] There is a genuine question he

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

On 6/22/2021 3:52 PM, Brett Cannon wrote: One thing I will remind people is I personally have led the work to move this project from: 1. SourceForge to our own infrastructure 2. Mercurial to git 3. Our own infrastructure to GitHub for code management At this point, I (once a skeptic) agre

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

On 6/23/2021 4:28 PM, Inada Naoki wrote: FWIW, GitHub announced new powerful Issues today. https://github.com/features/issues It may fill some gap between GitHub Issues and Roundup. I signed up for the beta waiting list so I could experiment with it. Someone else would have to sign up 'Python

[Python-Dev] Re: Critique of PEP 657

On 6/30/2021 12:30 PM, Ammar Askar wrote: I don't think we're making strong claims that the full `(line, end_line, column, end_column)` should be the canonical representation for exception locations. The only concrete place we suggest their usage is in the printing of tracebacks. sys.__excepth

[Python-Dev] Re: Critique of PEP 657

> Then how will modules that customizes traceback presentation, such as idlelib, be able to get the 4-tuple for a particular traceback entry? From the exception, you can get the code object and from the code object the extra information using the Python API: Example: >>> try: ...   1/0 ...

[Python-Dev] Re: Critique of PEP 657

On 6/30/2021 5:30 PM, Pablo Galindo Salgado wrote: Also, notice we are extending the traceback module (in Python) to support this, so you probably can also leverage those changes so you don't need to mess with code objects yourself :) IDLE currently uses traceback.extract_tb and traceback.prin

[Python-Dev] Re: Stale PR

On 7/6/2021 12:29 PM, Brian Curtin wrote: Before looking at the code, my first question would be about the description: "I kinda ran out of time, i suspect more testing is due." If you were out of time then it's probably not done and maybe lacks the tests you initially thought it did, so did y

[Python-Dev] Re: 咨询python的相关问题(Consult python related issues)

On 7/28/2021 6:46 AM, C wrote: Hello, I would like to consult related issues encountered when reading the python language reference manual, Ask question on python-list, which is about *using* python. https://mail.python.org/mailman/listinfo/python-list python-dev is for discussion of *develop

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

On 8/11/2021 7:56 AM, Larry Hastings wrote: So, here's an idea, credit goes to Eric V. Smith.  What if we tweak how decorators work, /jst slghtly/, so that they work like the workaround code above? Specifically: currently, decorators are called just after the function or class object

[Python-Dev] Re: Making code object APIs unstable

On 8/13/2021 1:24 PM, Guido van Rossum wrote: In 3.11 we're changing a lot of details about code objects. Part of this is the "Faster CPython" work, part of it is other things (e.g. PEP 657 -- Fine Grained Error Locations in Tracebacks). As a result, the set of fields of the code object is cha

[Python-Dev] Re: Making code object APIs unstable

On 8/13/2021 8:45 PM, Guido van Rossum wrote: Now, backwards compatibility is still nothing to sneeze at, but at least we don't have to hem and haw about ABI compatibility. If back compatibility were our sacred prime directive, then we would not (or should not) have changed code objects in wa

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

SUMMARY: If you, Marco, want to get dicts subclasses made faster and you seriously think that they can be, open a proper issue on bugs.python.org., as I describe in 3 below. In any case, drop this tread, which started off wrongly. August 6, in response to the weekly post, Summary of Python tra

[Python-Dev] Re: Dropping out of this list

On 8/18/2021 9:37 PM, Edwin Zimmerman wrote: On 8/18/21 9:18 PM, Jonathan Goble wrote: I am mostly a lurker, but I am also considering unsubscribing if someone doesn't step in and stop the mess +1 Both the email and newsreader parts of Thunderbird have an option called Ignore Thread. Do y

[Python-Dev] Re: Dropping out of this list

As I said before, I am using Ignore Thread to ignore these threads. Please stop evading my wishes by sending me private discourtesy copies. At least 3 people have done that when *not* responding to anything I wrote. -- Terry Jan Reedy ___ Python-De

[Python-Dev] Re: Dropping out of this list

st. button because I'm lazy. On Thu, 19 Aug 2021 at 20:38, Terry Reedy wrote: As I said before, I am using Ignore Thread to ignore these threads. Please stop evading my wishes by sending me private discourtesy copies. At least 3 people have done that when *not* responding to anything

[Python-Dev] Re: New moderator

On 8/23/2021 4:02 PM, Ethan Furman wrote: After petitioning the Steering Council I have been added as a moderator for the Python Dev mailing list.  I was already the moderator of four other Python lists. Thank you Ethan. I think you have done better than I would have with python-list. My

[Python-Dev] Re: Is anyone relying on new-bugs-announce/python-bugs-list/bugs.python.org summaries

On 8/23/2021 6:11 PM, Ammar Askar wrote: Hey everyone, As part of PEP 588, migrating bugs.python.org issues to Github, there are two current mailing list related items that need a replacement or need to be turned down. 1. Weekly summary emails with bug counts and issues from the week, example:

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

On 8/25/2021 6:48 PM, Steve Holden wrote: I suspect it's the same motivation that makes us comment out a block of code rather than deleting it, even though we know the VCS will let us retirive it whenever we want. If I'm wrong it won't be fatal. Or surprising ;-) Kind regards, Steve On Wed,

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

On 9/9/2021 1:56 PM, Ethan Furman wrote: On 9/9/21 9:37 AM, Barry Warsaw wrote: > While I think int.to_bytes() is pretty obscure (I knew about it, forgot about it, and learned > about it again!) I’m not so sure it’s any less obscure than a proposed bytes.fromint(). > > So why don’t we jus

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

On 9/15/2021 12:33 AM, Guido van Rossum wrote: On Tue, Sep 14, 2021 at 9:03 PM Steven D'Aprano > wrote: On Tue, Sep 14, 2021 at 12:33:32PM -0700, Guido van Rossum wrote: > My view of this is: > > A. It's not an iterator if it doesn't define `__next_

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

On 9/16/2021 3:02 AM, Paul Moore wrote: The debate here is (I think!) whether an *iterator* that is not also an *iterable* is a valid iterator. This framing of the question seems biased in that it initially uses 'iterator' to mean 'object with __next__ but not __iter__' whe the propriety of

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

On 9/20/2021 7:18 AM, Pablo Galindo Salgado wrote: there are some interesting things we **could** (emphasis on could) get out of this and I wanted to discuss what people think about them. * The parser will allow nesting quote characters. This means that we **could** allow reusing the same quo

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

On 9/20/2021 8:46 AM, Serhiy Storchaka wrote: 20.09.21 14:18, Pablo Galindo Salgado пише: * The parser will likely have "\n" characters and backslashes in f-strings expressions, which currently is impossible: What about characters "\x7b", "\x7d", "\x5c", etc? What about newlines in single quo

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

On 9/20/2021 11:48 AM, Eric V. Smith wrote: When I initially wrote f-strings, it was an explicit design goal to be just like existing strings, but with a new prefix. That's why there are all of the machinations in the parser for scanning within f-strings: the parser had already done its duty,

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

On 9/21/2021 3:29 PM, Guido van Rossum wrote: On Tue, Sep 21, 2021 at 11:49 AM Eric V. Smith > wrote: [Pablo] * The parser will allow nesting quote characters. This means that we **could** allow reusing the same quote type in nested expressions like th

[Python-Dev] Re: Changing exception text in micro releases

On 9/24/2021 10:46 AM, Eric V. Smith wrote: On 9/24/2021 10:39 AM, Ethan Furman wrote: On 9/24/21 6:51 AM, Eric V. Smith wrote: > This is clearly an improvement. My question is: is it okay to backport this to 3.9 and 3.10? I > think we have a rule that it's okay to change the exception text,

[Python-Dev] Re: PEP 654 except* formatting

On 10/4/2021 9:57 AM, Ammar Askar wrote: Throwing in another +1 for `except group`. It's explicit, doesn't introduce new punctuation and avoids confusion with unpacking. I agree for same reasons. And avoids more bikeshedding. I checked and if 'except group' is added to keyword.kwlist *befor

Re: [Python-Dev] Rationale for different signatures of tuple.__new__ and namedtuple.__new__

Later today you posted "Differences creating tuples and collections.namedtuples" on python-list. http://thread.gmane.org/gmane.comp.python.general/726849 That *is* the proper place to make observations about current Python and ask questions about why it is the way it is and how to work around

Re: [Python-Dev] Python 2.7 buffer and memoryview documentation (issue# 17145)

On 2/19/2013 12:33 PM, Demian Brecht wrote: Comment on patch on issue. Also, are contributor agreements also required for documentation? I believe so, especially for substantial patches like yours. Just submit one and be done with it. You probably should choose the Academic License. http://

Re: [Python-Dev] request._parse

On 2/23/2013 2:36 PM, Demian Brecht wrote: Hope this question belongs here and not in python-ideas, but I'm curious about _parse in the Request object. Specifically, why it was decided to write a custom parse function when the likes or urlparse or urlsplit do essentially the same thing. urllib.

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

On 2/23/2013 12:46 PM, Nick Coghlan wrote: For the standard library, we *really don't care* about any of those things, because we're currently using integers and strings for everything, so we can't add structure without risking breaking other people's code. However, just as we can get away with

Re: [Python-Dev] Bug scipy v.11 library in python2.7

On 2/25/2013 4:49 AM, Om Damani (ओम दम्माणी) wrote: I wish to report the following bug. Bugs should be reported on the issue tracker for the particular project. http://www.scipy.org/ has a Report Bugs button at the top. -- Terry Jan Reedy ___ Pytho

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

On 2/25/2013 12:35 PM, Ethan Furman wrote: But this I don't, and in both mine, Ted's, and Alex's versions enums from different groups do not compare equal, regardless of the underlying value. Of course, this does have the potential problem of `green == 1 == bee` but not `green == bee` which wou

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

On 2/25/2013 6:53 PM, Greg Ewing wrote: Barry Warsaw wrote: >>> Colors = make('Colors', 'red green blue'.split()) >>> Animals = make('Animals', 'ant bee cat'.split()) >>> Colors.green == Animals.bee The currently suggested solution to that seems to be to make comparison non-transit

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

On 2/25/2013 2:48 PM, Antoine Pitrou wrote: On Mon, 25 Feb 2013 11:34:35 -0800 Ethan Furman wrote: Antoine, question for you: Do you think enums from different groupings should compare equal? Equality should be mostly transitive so, yes, I think they should. Or if they do not, then they sh

Re: [Python-Dev] Announcing PEP 436: The Argument Clinic DSL

On 2/25/2013 7:11 PM, Larry Hastings wrote: Following up on a conversation on python-dev from last December: http://mail.python.org/pipermail/python-dev/2012-December/122920.html I'm pleased to announced PEP 436, proposing Argument Clinic for adoption into the CPython source tree. htt

Re: [Python-Dev] cffi in stdlib

On 2/26/2013 10:13 AM, Maciej Fijalkowski wrote: I would like to discuss on the language summit a potential inclusion of cffi[1] into stdlib. How does it compare in terms of speed. One reason ctypes has not replaces hand-tuned swig is that it apparently is much slower. I know that someone, f

Re: [Python-Dev] Announcing PEP 436: The Argument Clinic DSL

On 2/26/2013 1:47 PM, Larry Hastings wrote: On 02/26/2013 08:11 AM, Terry Reedy wrote: The PEP gives an internal, developer-focused rationale. I think there is also an external, user-focused rationale. As much as possible (with obvious caveats about type introspection), I think it should be

Re: [Python-Dev] cffi in stdlib

On 2/27/2013 3:31 PM, Paul Moore wrote: from ctypes import windll MessageBox = windll.User32.MessageBoxW MessageBox(0, "Hello, world!", "Title", 0) > Note - I wrote this from memory, Gee, that is pretty easy. Worked perfectly -- Terry Jan Reedy ___

Re: [Python-Dev] Disabling string interning for null and single-char causes segfaults

On 3/2/2013 10:08 AM, Nick Coghlan wrote: On Sat, Mar 2, 2013 at 1:24 AM, Stefan Bucur wrote: Hi, I'm working on an automated bug finding tool that I'm trying to apply on the Python interpreter code (version 2.7.3). Because of early prototype limitations, I needed to disable string interning i

Re: [Python-Dev] Introducing Electronic Contributor Agreements

On 3/4/2013 11:36 AM, Brett Cannon wrote: On Mon, Mar 4, 2013 at 11:30 AM, Brian Curtin mailto:br...@python.org>> 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

Re: [Python-Dev] Introducing Electronic Contributor Agreements

On 3/4/2013 3:46 PM, Antoine Pitrou wrote: On Mon, 04 Mar 2013 15:46:48 -0500 Terry Reedy wrote: On 3/4/2013 11:36 AM, Brett Cannon wrote: With this in place I would like to propose that all patches submitted to bugs.python.org <http://bugs.python.org> must come from someone who has

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

On 3/4/2013 5:24 PM, Barry Warsaw wrote: What I'm looking for is something that automated tools can use to easily discover how to run a package's tests. I want it to be dead simple for developers of a package to declare how their tests are to be run, and what I am writing a package that has t

Re: [Python-Dev] Introducing Electronic Contributor Agreements

On 3/4/2013 7:51 PM, Mark Lawrence wrote: Who's talking source code, you're previously mentioned *ALL* patches needing a CLA. Does this mean you have to sign a CLA for a one line documentation patch? It it is a one char typo, I would not bother downloading the patch, or adding a person to AC

[Python-Dev] VC++ 2008 Express Edition now locked away?

Clicking this link http://www.microsoft.com/en-us/download/details.aspx?id=14597 on this Developer Guide page http://docs.python.org/devguide/setup.html#windows now returns a "We are sorry, the page you requested cannot be found." page with search results. The first search result http://social.ms

Re: [Python-Dev] Introducing Electronic Contributor Agreements

On 3/6/2013 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 code without the CLA signed. Now I'm not that paranoid, but I'm

Re: [Python-Dev] VC++ 2008 Express Edition now locked away?

On 3/6/2013 11:55 AM, Chris Angelico wrote: Someone would have to check, but in most cases, software licenses govern the use, more than the distribution. If you're allowed to download it free of charge from microsoft.com, you should be able to get hold of it in some other way and it be exactly t

Re: [Python-Dev] VC++ 2008 Express Edition now locked away?

On 3/6/2013 12:29 PM, Steve Dower wrote: From: Case Van Horsen The "Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1" is still available for download. It includes the command line compilers that are used with VS 2008. I have used to create extensions for Python 2.6 to 3.2. There

Re: [Python-Dev] Introducing Electronic Contributor Agreements

On 3/4/2013 3:46 PM, Antoine Pitrou wrote: On Mon, 04 Mar 2013 15:46:48 -0500 Terry Reedy wrote: Either policy could be facilitated by tracker changes. In order to see the file upload box, one must login and the tracker knows who has a CLA on file (as indicated by a * suffix on the name). If

[Python-Dev] PEP 434: IDLE Enhancement Exception

nches Version: $Revision$ Last-Modified: $Date$ Author: Todd Rovito , Terry Reedy BDFL-Delegate: Nick Coghlan Status: Draft Type: Informational Content-Type: text/x-rst Created: 16-Feb-2013 Post-History: 16-Feb-2013 Abstract Most CPython tracker issues are classified as behavi

Re: [Python-Dev] FileCookieJars

On 3/10/2013 4:59 PM, R. David Murray wrote: To be clear, just passing the stdlib tests is *not* sufficient to think that backward compatibility is not likely to be broken. Deciding about the likelihood of breakage is a hard problem, to which we generally employ gut-level heuristics :) (And cod

Re: [Python-Dev] About issue 6560

On 3/14/2013 6:48 PM, "Martin v. Löwis" wrote: Am 14.03.13 15:15, schrieb Ani Sinha: I was looking into a mechanism to get the aux fields from recvmsg() in python and I came across this issue. Looks like this feature was added in python 3.3. Is there any reason why this feature was not added for

[Python-Dev] Matching __all__ to doc: bugfix or enhancement?

The timeit doc describes four public attributes. The current timeit.__all__ only lists one. http://bugs.python.org/issue17414 proposes to expand __all__ to include all four: -__all__ = ["Timer"] +__all__ = ["Timer", "timeit", "repeat", "default_timer"] The effect of the change is a) help(timit) w

Re: [Python-Dev] Matching __all__ to doc: bugfix or enhancement?

On 3/15/2013 12:15 AM, Guido van Rossum wrote: So it's a new feature, albeit a small one. I do see that it shouldn't be backported, but I don't see any worries about doing it in 3.4. Adding new functions/classes/constants to modules happens all the time, and we never give a second thought to user

Re: [Python-Dev] IDLE in the stdlib

On 3/20/2013 2:22 PM, Eli Bendersky wrote: On Wed, Mar 20, 2013 at 11:09 AM, R. David Murray mailto:rdmur...@bitdance.com>> wrote: On Wed, 20 Mar 2013 09:41:53 -0700, Eli Bendersky mailto:eli...@gmail.com>> wrote: Personally, I think that IDLE reflects badly on Python in more ways than one.

Re: [Python-Dev] IDLE in the stdlib

On 3/20/2013 3:59 PM, Brian Curtin wrote: On Wed, Mar 20, 2013 at 2:51 PM, Xavier Morel wrote: That would be a blow to educators, but also Windows users: while the CLI works very nicely in unices, that's not the case with the win32 console which is as best as I can describe it a complete turd,

Re: [Python-Dev] IDLE in the stdlib

On 3/20/2013 6:48 PM, Kurt B. Kaiser wrote: It seems to me that we are seeing increasing use of IDLE for beginner training. I've seen several recent Python books that use IDLE as their programming environment, and which include IDLE screen captures in the text. Well, one can hardly use Command

[Python-Dev] A 'common' respository? (was Re: IDLE in the stdlib)

On 3/20/2013 8:15 PM, Terry Reedy wrote: I will discuss repository separation in another response Here is a radical idea I have been toying with: set up a 'common' repository to 'factor out' files that are, could be, or should be the same across versions. The &#x

Re: [Python-Dev] IDLE in the stdlib

On 3/20/2013 12:41 PM, Eli Bendersky wrote: Personally, I think that IDLE reflects badly on Python in more ways than one. It's badly maintained, quirky and ugly. Ugly is subjective: by what standard and compared to what? I suggested in my previous response why I think 'badly maintained' is u

Re: [Python-Dev] cpython: Issue #13248: removed deprecated and undocumented difflib.isbjunk, isbpopular.

On 3/20/2013 2:13 PM, R. David Murray wrote: On Wed, 20 Mar 2013 05:23:43 -0700, Eli Bendersky wrote: A mention in Misc/NEWS can't hurt here, Terry. Even though it's undocumented, some old code could rely on it being there and this code will break with the transition to 3.4 Will do. Note th

Re: [Python-Dev] IDLE in the stdlib

On 3/20/2013 8:38 PM, Neil Hodgson wrote: Terry Reedy: Broken (and quirky): it has an absurdly limited output buffer (under a thousand lines) The limit is actually lines. I clicked Start / All programs / Python 3.3 / Python (command line) >>> help(str) (several times) and

Re: [Python-Dev] IDLE in the stdlib

On 3/20/2013 11:54 PM, Eli Bendersky wrote: On Wed, Mar 20, 2013 at 8:32 PM, Terry Reedy Ugly is subjective: by what standard and compared to what? Compared to other existing Python IDEs and shells which are layered on top of modern GUI toolkits that are actively developed to keep with

Re: [Python-Dev] IDLE in the stdlib

On 3/21/2013 12:36 AM, Glenn Linderman wrote: On 3/20/2013 5:15 PM, Terry Reedy wrote: Broken (and quirky): it has an absurdly limited output buffer (under a thousand lines) People keep claiming that Windows CMD has a limited output buffer. It is configurable, at least to lines, which is

Re: [Python-Dev] IDLE in the stdlib

On 3/21/2013 12:32 AM, Kurt B. Kaiser wrote: Well, spending a lot of time backporting new features is not my idea of fun. OTOH, I have no objection. I intentionally did not say in the PEP that it should be mandatory. Along those lines, I've thought that IDLE should refrain from using the new

Re: [Python-Dev] A 'common' respository? (was Re: IDLE in the stdlib)

On 3/21/2013 2:06 AM, Philip James wrote: I hope I'm not coming across as pedantic, because I think you have some good arguments listed above, but shouldn't discussion like this go in python-ideas rather than python-dev? Normally yes. But since this is a counter-proposal or an alternate propos

Re: [Python-Dev] IDLE in the stdlib

On 3/21/2013 5:27 AM, Paul Moore wrote: Can I suggest that debates about the capability of Windows command line programming are off-topic here? I respectfully disagree, unless you say that the whole thread is off topic. If it is okay for people to say that IDLE, including the IDLE interactiv

Re: [Python-Dev] IDLE in the stdlib

On 3/21/2013 5:41 AM, Paul Moore wrote: On 21 March 2013 06:54, Devin Jeanpierre wrote: On Thu, Mar 21, 2013 at 2:42 AM, Terry Reedy wrote: I think being frozen in the late 1990s is better than being frozen in the early 1980s, like Command Prompt is. In fact, I think we should 'depr

Re: [Python-Dev] IDLE in the stdlib

On 3/21/2013 5:20 AM, Antoine Pitrou wrote: Le Thu, 21 Mar 2013 02:42:33 -0400, Terry Reedy a écrit : On 3/20/2013 11:54 PM, Eli Bendersky wrote: On Wed, Mar 20, 2013 at 8:32 PM, Terry Reedy Ugly is subjective: by what standard and compared to what? Compared to other existing Python

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