[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

On 01/24/2020 05:02 AM, Eric V. Smith wrote: On 1/24/2020 5:50 AM, Ivan Levkivskyi wrote: On Fri, 24 Jan 2020 at 10:05, Victor Stinner wrote: The proposal is to give one year to project maintainers to drop Python 2.7 support, since Python 2.7 end of support just happened a few weeks ago (2020

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

On 01/31/2020 10:47 AM, Mike Miller wrote: On 2020-01-23 07:20, Victor Stinner wrote: Python 3.9 introduces many small incompatible changes which broke tons There's a well-known and established way of signaling breaking changes in software platforms—it is to increment the major version numb

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

breaks In other words, we should keep compatibility, or not. In any case, from the looks of it these will be tiny breaks compared to the Unicode transition. Ethan Furman wrote: I've gotta say, I like that plan. Instead of going to x.10, go to x+1.0. Every ten years we bump the major version

[Python-Dev] Re: Merging PRs without CLA signed

On 02/23/2020 08:44 PM, Guido van Rossum wrote: (What is it with typos anyway? Why do people feel the need to invoke megabytes if not gigabytes of internet traffic to correct a word that every reader can easily correct in their mind?) Typos are like skate boarding on fresh asphalt and then h

[Python-Dev] Re: PEP 614 accepted

On 03/03/2020 10:13 AM, Barry Warsaw wrote: Congratulations to PEP author Brandt and PEP sponsor Guido, and thanks to everyone who’s worked on this PEP and its implementation. Congratulations!! -- ~Ethan~ ___ Python-Dev mailing list -- python-dev@p

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

On 03/20/2020 11:52 AM, Dennis Sweeney wrote: Browser Link: https://www.python.org/dev/peps/pep-0616/ PEP: 616 Title: String methods to remove prefixes and suffixes Thank you, Dennis, for putting this together! And Eric for sponsoring. :) Overall I think it's a good idea, but... Alternati

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

On 03/24/2020 01:37 PM, Eric V. Smith wrote: On 3/24/2020 3:30 PM, Steve Dower wrote: On 24Mar2020 1849, Brett Cannon wrote: -1 on "cut*" because my brain keeps reading it as "cute". +1 on "trim*" as it is clear what's going on and no confusion with preexisting methods. +1 on "remove*" for the

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

Dennis Sweeney wrote: Steven D'Aprano wrote: Dennis Sweeney wrote: I think then maybe it would be preferred to use the something like the following in the PEP: def cutprefix(self, prefix, /): if isinstance(prefix, str): if self.startswith(prefix): return self[len(pr

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

On 03/24/2020 06:10 PM, Victor Stinner wrote: Ethan Furman: "This is why replace() still only takes a single substring to match and this isn't supported: (...)" Correction: The above quote belongs to Steven D'Aprano. -- ~Ethan~ __

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

the methods should return base str objects even when called on str subclasses. Ethan Furman wrote: --- The Python interpreter in my head sees self[:] and returns a copy. Dennis Sweeney wrote: --- I think I'm still in the camp that ``return self[:]``

[Python-Dev] Enum._convert should change __repr__ and/or __str__ to use module name instead of class name

Serhiy had the idea of having Enum._convert also modify the __str__ and __repr__ of newly created enumerations to display the module name instead of the enumeration name (https://bugs.python.org/msg325007): --> socket.AF_UNIX ==> --> print(socket.AF_UNIX) AddressFamily.AF_UNIX==> s

[Python-Dev] Re: Enum._convert should change __repr__ and/or __str__ to use module name instead of class name

On 03/25/2020 12:54 PM, Ethan Furman wrote: --> socket.AF_UNIX    ==>  --> print(socket.AF_UNIX) AddressFamily.AF_UNIX    ==>  socket.AF_UNIX An important point I should have included -- the definition of AddressFamily: IntEnum._convert_( &#

[Python-Dev] Re: Enum._convert should change __repr__ and/or __str__ to use module name instead of class name

On 03/25/2020 06:53 PM, Ivan Pozdeev via Python-Dev wrote: A diagnostic is always done by the same algorithm: 1) Identify the exact place in code where the problem manifests itself 2) Examine the state of the program at that moment to find out which if the values are wrong 3) Track the wrong v

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

First off, thank you for being so patient -- trying to champion a PEP can be exhausting. On 03/26/2020 05:22 PM, Dennis Sweeney wrote: Ethan Furman wrote: I don't understand that list bit -- surely, if I'm bothering to implement removeprefix and removesuffix in my subclass, I

[Python-Dev] Re: Enum._convert should change __repr__ and/or __str__ to use module name instead of class name

On 03/27/2020 05:21 PM, Ivan Pozdeev via Python-Dev wrote: On 26.03.2020 19:24, Ethan Furman wrote: On 03/25/2020 06:53 PM, Ivan Pozdeev via Python-Dev wrote: A diagnostic is always done by the same algorithm: 1) Identify the exact place in code where the problem manifests itself 2) Examine

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On 05/10/2020 09:04 AM, Brandt Bucher wrote: https://www.python.org/dev/peps/pep-0618 Many Python users find that most of their zip usage I don't think you have enough data to make that claim, unless by "many" you mean five or more. but silently start producing shortened, mismatched re

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On 05/11/2020 11:48 PM, Brandt Bucher wrote: On 05/10/2020 14:39 PM, Ethan Furman wrote: On 05/10/2020 09:04 AM, Brandt Bucher wrote: However, zip_longest is really another beast entirely No, it isn't. It has a completely independent implementation, a different interface, lives

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On 05/11/2020 11:48 PM, Brandt Bucher wrote: On 05/10/2020 14:39, Ethan Furman wrote: On 05/10/2020 09:04 PM, Brandt Bucher wrote: the author has counted dozens of other call sites in Python's standard library and tooling where it would be appropriate to enable this new feature immedi

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On 05/13/2020 06:04 AM, Antoine Pitrou wrote: On Tue, 12 May 2020 11:36:38 -0700 Ethan Furman wrote: Also, if a flag is used, won't that slow down every call to zip even when the flag is False? Why would it? Is that based on a rational analysis of how argument parsing works? Not the

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On 05/14/2020 05:43 AM, Antoine Pitrou wrote: On Wed, 13 May 2020 19:27:57 -0700 Ethan Furman wrote: On 05/13/2020 06:04 AM, Antoine Pitrou wrote: On Tue, 12 May 2020 11:36:38 -0700 Ethan Furman wrote: Also, if a flag is used, won't that slow down every call to zip even when the fl

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

't thinkit's beyond the realm of imagination for a future refactoring of severalof the "Mismatch cannot happen." cases to introduce a bug of this kind. Which seems besides the point. As you say, if the lengths are mismatched then a bug has appeared and if the check is nearly f

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On 06/01/2020 04:36 AM, Nick Coghlan wrote: Reading this thread and the current PEP, the main question I had was whether it might be better to flip the sense of the flag and call it "truncate". So the status quo would be "truncate=True", while the ValueError could be requested by passing an e

[Python-Dev] type() does not call __prepare__?

From stackoverflow [1] # metaprepare.py class Meta1(type): @classmethod def __prepare__(mcs, name, bases): print('call prepare') return {} def __new__(mcs, name, bases, parameters): return super().__new__(mcs, name, bases, parameters) class A

[Python-Dev] Re: Should we be making so many changes in pursuit of PEP 554?

On 06/05/2020 07:32 AM, Mark Shannon wrote: 3. It can be implemented on top of the multiprocessing module, for testing. A more efficient implementation can be developed once sub-interpreters prove useful. Isn't part of the impetus for in-process sub-interpreters the Python-embedded-in-langu

[Python-Dev] Re: Accepting PEP 618: zip(strict=True)

On 06/16/2020 04:07 PM, Guido van Rossum wrote: I am hereby accepting PEP 618. Congratulations, Brandt! -- ~Ethan~ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.o

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 06/23/2020 09:01 AM, Guido van Rossum wrote: Very nice! I am totally in favor (with some bike-shedding, of course). First, a formatting comment: A new sentence immediately following formatted code needs more space -- it looks like the same sentence otherwise. Will putting two spaces after

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 06/23/2020 12:49 PM, Barry Warsaw wrote: Maybe the PEP could support this syntax: case in 401, 403, 404: That seems like it would be both unambiguous and semantically obvious. Unfortunately, that means: Is the object a three-tuple with the values 401, 403, and 404? -- ~Ethan~ ___

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 06/23/2020 02:48 PM, Barry Warsaw wrote: On Jun 23, 2020, at 13:50, Ethan Furman wrote: On 06/23/2020 12:49 PM, Barry Warsaw wrote: Maybe the PEP could support this syntax: case in 401, 403, 404: That seems like it would be both unambiguous and semantically obvious. Unfortunately

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 06/23/2020 04:26 PM, Guido van Rossum wrote: On Tue, Jun 23, 2020 at 11:41 AM Ethan Furman wrote: Testing my understanding -- the following snippet from the PEP      match group_shapes():          case [], [point := Point(x, y), *other]: will succeed if group_shapes

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 06/23/2020 09:01 AM, PEP 622 wrote: from enum import Enum class Color(Enum): BLACK = 1 RED = 2 BLACK = 1 RED = 2 match color: case .BLACK | Color.BLACK: print("Black suits every color") case BLACK: # This will just assign a new value to BLACK. ... As othe

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 06/23/2020 10:31 PM, Chris Angelico wrote: On Wed, Jun 24, 2020 at 3:21 PM Ethan Furman wrote: On 06/23/2020 09:01 AM, PEP 622 wrote: from enum import Enum class Color(Enum): BLACK = 1 RED = 2 BLACK = 1 RED = 2 match color: case .BLACK | Color.BLACK: print("

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 06/23/2020 10:11 PM, Ethan Furman wrote: As others have noted, the leading dot to disambiguate between a name assignment and a value check is going to be a problem. I suspect I wasn't as clear as I could have been, so let me try again (along with some thinking-out-loud...).

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 06/23/2020 09:01 AM, Guido van Rossum wrote: PEP 622 Okay, I took Paul Moore's advice and went looking in existing code for some examples, and came across the following: if isinstance(v, int): # v is an offset elif isinstance(v, str): # v is a docstring elif is

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 06/24/2020 08:57 AM, mi...@drach.uk wrote: To me match also sound confusing as a keyword. You don't match things to cases in English. Maybe match x: against 1? https://idioms.thefreedictionary.com/match+against Python uses English words, but is not English. Having said that, you can "m

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 06/24/2020 11:08 AM, Guido van Rossum wrote: Nearly every other language whose pattern matching syntax we've examined uses _ as the wildcard. The authors don't feel very strongly about whether to use `else:` or `case _:`. The latter would be possible even if we added an explicit `else` cla

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 06/24/2020 01:49 PM, Tim Peters wrote: I too thought "why not else:?" at first. But "case _:" covers it in the one obvious way after grasping how general wildcard matches are. "case _:" is easy to miss -- I missed it several times reading through the PEP. Introducing "else:" too would be

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 06/25/2020 03:00 AM, Greg Ewing wrote: On 25/06/20 7:50 pm, Anders Munch wrote: Pascal is a precedent for this placement of 'case', Yes, but it doesn't use it with "match". In fact it doesn't have any keyword in front of the values to be matched; it goes like    case n of   1: ...;

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

On 06/25/2020 04:07 PM, Brandt Bucher wrote: Pablo Galindo Salgado wrote: ...users can do a positional match against the proxy with a name pattern: match input: case datetime.date(dt): print(f"The date {dt.isoformat()}" ...if 'datetime.date' were updated to implement a non-defaul

[Python-Dev] Re: PEP 622: Structural Pattern Matching

In this example code from the PEP: match shape: case Point(x, y): ... case Rectangle(x0, y0, x1, y1, painted=True): What is the "painted=True" portion doing? Is it requiring that the painted attribute of the shape object be True in order to match? -- ~Ethan~ __

[Python-Dev] Recent PEP-8 change

On 06/29/2020 08:13 AM, Keara Berlin wrote: Hi all, I didn't mean for there to be significant differences between what I posted here versus in the commit message. Sorry for any confusion around that! Thank you for putting them both in one place here - that is helpful. To be clear, the propos

[Python-Dev] Re: Recent PEP-8 change

On 06/30/2020 05:03 AM, Łukasz Langa wrote: On 30 Jun 2020, at 12:44, Ethan Furman mailto:et...@stoneleaf.us>> wrote: Of course I don't know if Keara or Guido knew any of this, but it certainly feels to me that the commit message is ostracizing an entire family line because t

[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

On 06/30/2020 07:07 AM, Giampaolo Rodola' wrote: On Tue, Jun 30, 2020 at 3:16 PM Thomas Wouters wrote: Please report all CoC violations to the CoC WG. Please don't. As far as I'm concerned, me and Thomas are fine. Also, as I said, I don't like CoCs nor appealing to them. This is a public

[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

On 06/29/2020 06:21 AM, Nathaniel Smith wrote: It's not Strunk and White per se, it's the idea of enforcing "standard English", where "standard" here means "talks like a American with an Ivy league education". I believe the issue is writing, not talking. There's nothing wrong with being igno

[Python-Dev] Re: Recent PEP-8 change

On 07/02/2020 10:19 AM, David Mertz wrote: On Thu, Jul 2, 2020 at 12:58 PM Piper Thunstrom wrote: On 07/02/2020 David Mertz wrote: TL;DR: It's not a recent usage; it was OK in 1375. Over the last handful of decades, singular "they" has been explicitly taught as inappropriate. My own college

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 07/08/2020 08:30 AM, Luciano Ramalho wrote: As I first read a `match` statement, and I see an `else` clause, I know for sure that *something* will happen. If no `else` clause is present, I know it's possible nothing will happen. It's the same thing with `else` in `if`, `while`, `for`, `try` s

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 07/08/2020 08:02 AM, Guido van Rossum wrote: Today I’m happy (and a little trepidatious) to announce the next version of PEP 622, Pattern Matching. All in all I like it a lot! As authors we welcome Daniel F Moisset in our midst Welcom, Daniel, and thank you! That said, the new version

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 07/08/2020 10:44 AM, Ethan Furman wrote: So namespaced variables only...  is there a recommendation on handling global() and local() type variables? Okay, some off-list discussion clarified that for me: - easiest way is to use a guard ``` def foo(x, spam): match x

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 07/11/2020 04:20 AM, Paul Sokolovsky wrote: Actually, the whole argument in PEP 622 regarding "else:", that its placement is ambiguous sounds like a rather artificial write-off. Individual "case"'s are aligned together, but suddenly, it's unclear how to align the default case, introduced by "

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 07/11/2020 10:29 AM, Jim J. Jewett wrote: To me, "else:" has a slightly different meaning than "case _:" case _: essentially a default, ensuring that the match logic is complete. else: OK, the subject of this match failed, here is our fallback logic. Whether this distinctio

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 07/11/2020 03:31 PM, Guido van Rossum wrote: On Sat, Jul 11, 2020 at 2:45 PM Ethan Furman wrote: On 07/11/2020 10:29 AM, Jim J. Jewett wrote: To me, "else:" has a slightly different meaning than "case _:"           case _:  essentially a default, ensuring tha

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 07/14/2020 09:22 AM, Jim J. Jewett wrote: Larry Hastings wrote: As for leveraging the convention of using '_' for values you don't care about in Python--that's actually why I /don't/ like it as the wildcard pattern.  To date, everyone who uses '_' understands it's just an identifier, no diff

[Python-Dev] Re: PEP 622: Structural Pattern Matching (version 2)

On 07/14/2020 11:05 AM, Mark Shannon wrote: On 14/07/2020 5:25 pm, Tobias Kohn wrote: On 07/14/2020, Mark Shannon wrote: In future, could you avoid editing emails when replying to them? A lot of context can get lost. I appreciate posters who take the time to trim the parts of an email that

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

PEP 626 wrote: Abstract Python should guarantee that when tracing is turned on, "line" tracing events are generated for all lines of code executed and only for lines of code that are executed. The sample code shows `return` events being executed, even when there is no `return` line -- doesn'

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 7/17/20 8:26 AM, Gustavo Carneiro wrote: I kind of agree it is nicer to be more explicit.  But somehow x= looks ugly. It occurred to me (and, again, apologies if already been mentioned), we might use the `as` keyword here. The problem with any kind of sigil/keyword is that it becomes line

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

PEP 626: Rather than attempt to fix the co_lnotab attribute, a new method co_lines() will be added, which returns an iterator over bytecode offsets and source code lines. Why not attempt to fix co_lnotab? -- ~Ethan~ ___ Python-Dev mailing list --

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 7/30/20 8:35 AM, Rob Cliffe via Python-Dev wrote: The debate is still going on as to whether "capture" variables should be marked... I don't think the PEP authors are debating it any more. Quite frankly, I wish they would present to the SC and get accepted so we can get Pattern Matching ad

[Python-Dev] Enum and the Standard Library

As you may have noticed, Enums are starting to pop up all over the stdlib [1]. To facilitate transforming existing module constants to IntEnums there is `IntEnum._convert_`. In Issue36548 [2] Serhiy modified the __repr__ of RegexFlag: >>> import re >>> re.I re.IGNORECASE I think for

[Python-Dev] Re: Enum and the Standard Library

On 9/18/20 3:12 PM, Guido van Rossum wrote: > On 9/18/20 2:44 PM, Ethan Furman wrote: >> I'm looking for arguments relating to: >> >> - should _convert_ make the default __repr__ be >> module_name.member_name? > > I actually like the status quo for regul

[Python-Dev] Re: Enum and the Standard Library

On 9/18/20 6:41 PM, Guido van Rossum wrote: > On Fri, Sep 18, 2020 at 6:19 PM Ethan Furman wrote: >> So at this point, I think the choices are: >> >> Standard Enum >> __repr__ __str__ >>RegexFlag.IGNORECASE >> &

[Python-Dev] Re: Enum and the Standard Library

On 9/19/20 11:32 AM, Guido van Rossum wrote: > On Sat, Sep 19, 2020 at 1:29 AM Ethan Furman wrote: >> On 9/18/20 6:41 PM, Guido van Rossum wrote: >>> Another brainstorm (or brainfart): maybe repr() should show the >>> module/class and the name, and str() should only s

[Python-Dev] Re: Enum and the Standard Library

On 9/19/20 2:08 PM, Guido van Rossum wrote: I'm just trying to present an argument that if the str() of an enum was its name and the repr() was its "full name" (at least including the class) that would be pretty sweet. Well, we're still early enough in the 3.10 cycle we can make that change

[Python-Dev] unable to create PR on github

The green "create pull request" button is greyed out. I've tried reselecting the repos and branches, logging out and in, navigating to that screen via my own repository -- nothing is working. Any ideas? Thanks. -- ~Ethan~ ___ Python-Dev mailing lis

[Python-Dev] Re: unable to create PR on github

On 9/21/20 6:09 PM, Ethan Furman wrote: The green "create pull request" button is greyed out. I've tried reselecting the repos and branches, logging out and in, navigating to that screen via my own repository -- nothing is working. I have more data: I pushed another branch

[Python-Dev] Re: unable to create PR on github

And even more data: I added a body to the PR I was originally having trouble with: button stayed gray I went away for a while, say 5 - 10 minutes, and when I went back to that screen the button was green. I created the PR. -- ~Ethan~ ___ Python-D

[Python-Dev] Re: Enum and the Standard Library

On 9/22/20 12:11 AM, Serhiy Storchaka wrote: The only exception is StrEnum -- overriding __str__ of str subclass may be not safe. Some code will call str() implicitly, other will read the string content of the object directly, and they will be different. Following up on that: >>> import e

[Python-Dev] Re: [python-committers] Resignation from Stefan Krah

> the problem is only a specific behavior ("gatekeeper"). I'm (obviously) not on the SC, but I have to strongly disagree with you here -- there is nothing inherently wrong with being a gatekeeper, nor is there anything in the CoC about it. A gatekeeper can help ensure high-quality code, can pr

[Python-Dev] Re: Remove module's __version__ attributes in the stdlib

On 10/15/20 5:45 AM, Erlend Aasland wrote: FYI, sqlite3 has a /pysqlite/ “version" attribute iso. “__version__", stemming from its days outside of stdlib. It has held the value “2.6.0" since commit f9cee22, 2010-03-05. The proposal is to remove dunder version and friends, not plain version and

Re: [Python-Dev] Using logging in the stdlib and its unit tests

Stephen J. Turnbull wrote: They're not scared by that example. What you need is a paragraph below it that says """ Do you think the above is all you should need? If so, you're right. You can stop reading now. If you think you need more, we've got that, too. Read on (you may

Re: [Python-Dev] A grammatical oddity: trailing commas in argument lists -- continuation

Terry Reedy wrote: On 12/13/2010 2:17 PM, Antoine Pitrou wrote: On Mon, 13 Dec 2010 14:09:02 -0500 Alexander Belopolsky wrote: On Mon, Dec 13, 2010 at 11:54 AM, Guido van Rossum wrote: I'm at least +0 on allowing trailing commas in the situation the OP mentioned. FWIW, I am also about +0

[Python-Dev] Issue #6210: Exception Chaining missing method for suppressing context

I see the last comment was added on the 4th. Where should continued discussion take place -- bug-tracker, python-dev, ... ? ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: htt

Re: [Python-Dev] Issue #10348: concurrent.futures doesn't work on BSD

Martin v. Löwis wrote: And, again, the threading-based API in concurrent.futures should work fine anyway. Do you suggest we selectively disable the process-based API? Yes. Importing concurrent.futures.process should fail. If I understand correctly, it is possible to adjust BSD so that this w

Re: [Python-Dev] Possible optimization for LOAD_FAST ?

Cesare Di Mauro wrote: > 2010/12/29 "Martin v. Löwis" wrote: >> Am 28.12.2010 18:08, schrieb Lukas Lueg: Also, the load_fast in lne 22 to reference x could be taken out of the >>> loop as x will always point to the same object That's not true; a debugger may change the value of x. An

Re: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)

techto...@gmail.com wrote: I see no reason for b.p.o bureaucracy. It provides a place for discussion, and makes it easier to coordinate multiple efforts. ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listi

Re: [Python-Dev] Finally fix installer to add Python to %PATH% on Windows

Brian Curtin wrote: On Mon, Jan 31, 2011 at 15:43, anatoly techtonik > wrote: That's the easy part. It doesn't cover any of the real issues with doing this. Please be more specific. It will also help if you integrate this part while it's still hot. -- anatoly t. Th

Re: [Python-Dev] Finally fix installer to add Python to %PATH% on Windows

Chris Withers wrote: On 06/02/2011 15:25, Brian Curtin wrote: So put the new path before the old path, or replace it? The current patch appends to the end. I believe the last path wins in Windows land, so that would be fine. Actually, first one wins, as Windows starts at the beginning and st

[Python-Dev] %-formatting depracation

Greetings! According to these release notes in Python 3.0, %-formatting will be going away. http://docs.python.org/release/3.0.1/whatsnew/3.0.html#pep-3101-a-new-approach-to-string-formatting However, I was unable to find any further evidence of actual deprecation in 3.1 or 3.2... does any

Re: [Python-Dev] Fwd: deep question re dict as formatting input

Eric Smith wrote: On 2/22/2011 6:28 PM, Steve Holden wrote: On Feb 22, 2011, at 3:08 PM, Eric Smith wrote: Quoting PEP 3101: An example of the 'getitem' syntax: "My name is {0[name]}".format(dict(name='Fred')) It should be noted that the use of 'getitem' within a format string is muc

Re: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2

M.-A. Lemburg wrote: Still, the stdlib and test suite should be examples of using the correct names. I won't argue with the stdlib portion of your argument, but I would think that the best example of test code would be a complete and thorough check of all options. ~Ethan~ __

Re: [Python-Dev] Mercurial conversion repositories

Antoine Pitrou wrote: On Sat, 26 Feb 2011 12:32:04 +1000 Nick Coghlan wrote: On Fri, Feb 25, 2011 at 10:19 AM, Antoine Pitrou wrote: $ hg branches default68026:f12ef116dd10 3.268025:cef92ee1a323 2.768010:8174d00d0

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

Tim Golden wrote: On 07/03/2011 10:49, Mark Hammond wrote: On 7/03/2011 9:33 PM, Paul Moore wrote: That sounds like a fairly cool idea. So if I follow what you're suggesting, we'd have a single python.exe, probably installed in system32, which did the necessary command line juggling and shebang

Re: [Python-Dev] small commit emails nit

Antoine Pitrou wrote: Well, after a couple of days with the "cpython" prefix stripped, I have to say that I find it much less practical than it was before. Any other opinions? I would rather have it back. ~Ethan~ ___ Python-Dev mailing list Python-De

Re: [Python-Dev] API deprecations in Python 3, from a Python 2 perspective

Antoine Pitrou wrote: On Thu, 17 Mar 2011 19:23:30 -0400 Terry Reedy wrote: People should retest their stuff with each micro (bugfix) release anyway. I'm not sure they should. The point of having micro releases is that they don't bring any visible change in behaviour - apart from fixing bugs,

Re: [Python-Dev] Second draft: PEP397: Python launcher for Windows

Mike Driscoll wrote: On Tue, Mar 22, 2011 at 2:12 PM, Michael Foord wrote: On 22/03/2011 07:21, Mark Hammond wrote: Hi all, I've made some changes to the draft PEP and checked it into the PEP repository as PEP397. The reference implementation is currently being tracked at http://bugs.python

Re: [Python-Dev] Trimming the fat from "make quicktest" (was Re: I am now lost - committed, pulled, merged, what is "collapse"?)

s...@pobox.com wrote: Barry> Not if you keep in mind the appropriate use case for each of the Barry> separate make test targets. Programmers are lazy. They will often take the shortest path. Fix a small bug in module X which seems innocent enough, fail to recognize that it breaks modul

Re: [Python-Dev] Second draft: PEP397: Python launcher for Windows

Michael Foord wrote: To be honest I would be happy with registry entries instead as the alternative implementations can then add to their installers (or provide a script) to add the right registry entry. I'm partial to the config file method myself. I have this vague hope where this tool cou

Re: [Python-Dev] Python Core Mentorship program

On 3/25/2011 8:23 PM, Nick Coghlan wrote: On Sat, Mar 26, 2011 at 7:55 AM, Ben Finney wrote: One of the great things about a discussion forum open view for the public is that, when a topic comes up again in a *different* forum, I can easily point anyone to the existing discussion without requir

Re: [Python-Dev] Python Core Mentorship program

On 3/25/2011 2:55 PM, Ben Finney wrote: Guido van Rossum writes: On Fri, Mar 25, 2011 at 1:57 PM, Ben Finney wrote: Surely a forum specifically for mentorship will be more useful if outsiders can be directed to existing discussions, without needing to join the private club. This argument co

[Python-Dev] Issue Tracker

Greetings! I'm not sure where the best place is to ask this question, so I'll start here -- feel free to redirect me if necessary. I would like to have some software to keep track of bugs, to-do's, ideas, etc., etc. -- you know, an issue tracker! Naturally I thought of the one we use to tra

Re: [Python-Dev] Issue Tracker

Brian Curtin wrote: On Mon, Mar 28, 2011 at 15:05, Ethan Furman <mailto:et...@stoneleaf.us>> wrote: Greetings! I'm not sure where the best place is to ask this question, so I'll start here -- feel free to redirect me if necessary. I would like to have so

Re: [Python-Dev] Issue Tracker

Antoine Pitrou wrote: On Mon, 28 Mar 2011 15:14:20 -0500 Brian Curtin wrote: On Mon, Mar 28, 2011 at 15:05, Ethan Furman wrote: I would like to have some software to keep track of bugs, to-do's, ideas, etc., etc. -- you know, an issue tracker! Naturally I thought of the one we use to

Re: [Python-Dev] Please revert autofolding of tracker edit form

Glenn Linderman wrote: On 3/31/2011 9:52 AM, Terry Reedy wrote: I would like to try putting the comment box after the last (most recent) comment, as that is the message one most ofter responds to. Having to now scroll up and down between comment box and last message(s) is often of a nuisance

Re: [Python-Dev] Please revert autofolding of tracker edit form

Raymond Hettinger wrote: On Mar 31, 2011, at 9:52 AM, Terry Reedy wrote: I would like to try putting the comment box after the last (most recent) comment, as that is the message one most ofter responds to. Having to now scroll up and down between comment box and last message(s) is often of a n

Re: [Python-Dev] faulthandler is now part of Python 3.3

Victor Stinner wrote: I pushed my faulthandler module into the default branch (Python 3.3). Since one week, I fixed a lot of bugs (platform issues), improved the tests and Antoine wrote a new implementation of dump_backtraces_later() using a thread (instead of SIGALRM+alarm()). It should now work

Re: [Python-Dev] python and super

Ricardo Kirkner wrote: What would the semantics be of a super that intentially calls all >> siblings? In particular what is the return value of such a call? >> The implementation can't know how to combine the implementations >> in the inheritance chain and should refuse the tempation to guess.

Re: [Python-Dev] Adding test case methods to TestCase subclasses

Ben Finney wrote: Ethan Furman writes: Here we have django's TestCase that does *not* want to call unittest2.TestCase (assuming that's not a bug), but it gets called anyway because the Mixin3 sibling has it as a base class. So does this mean that TestCase and Mixin3 just don&#

Re: [Python-Dev] Adding test case methods to TestCase subclasses

Ben Finney wrote: Ethan Furman writes: >> Ben Finney wrote: >>> How can composition add test cases detectable by Python's ‘unittest’? >> Metaclasses, if's that an option... […] or a class decorator […] Both interesting, thank you. But Python 3 isn't

Re: [Python-Dev] Adding test case methods to TestCase subclasses

Ethan Furman wrote: Ben Finney wrote: Ethan Furman writes: 8<---test_compose.py--- import unittest ack! There should be an 'import new' here as well. :/ ___ Python-Dev mailing li

Re: [Python-Dev] Adding test case methods to TestCase subclasses

Ben Finney wrote: Both interesting, thank you. But Python 3 isn't an option for several projects where I'd like to use this. Okay, I took some time to try and figure this out (have I mentioned how much I love Python 3's clean-up?), and I have something -- lightly tested with methods, properti

Re: [Python-Dev] Buildbots and faulthandler

Victor Stinner wrote: Finally, I'm very happy to see that my faulthandler module was as useful as I expected [...] Congratulations! Nice work. ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-d

Re: [Python-Dev] Allowing import star with namespaces

Brendan Moloney wrote: We all know that doing: --> from pkg import * is bad because it obliterates the 'pkg' namespace. The strongest reason for not doing this is that it pollutes the current namespace, not that it obliterates the 'pkg' namespace. So why not allow something like: --> imp

<    9   10   11   12   13   14   15   16   >