[Python-Dev] Re: Switching to Discourse

I am a long time lurker here*, a professional and educational user of the language, a list moderator with practical exeperience managing a engaged community of a few thousand users over the course of a decade - and yes, I am old. I saw what happened when the young developers there insisted that we

[Python-Dev] Descriptions in unittest and avoiding confusion

For the edification of all involved, this post summarizes a somewhat surprising behavior in unittest around docstrings. In bpo-46126, I reported an issue where I’d observed that CPython developers were avoiding the use of docstrings in unittests due to what w

[Python-Dev] NASA Inquiry

REF: RITM1146898 Hello, my name is Charita Elmore and I am a Supply Chain Risk Management Coordinator at NASA.  As such, I ensure that all NASA acquisitions of Covered Articles comply with Section 208 of the Further Consolidated Appropriations Act, 2020, Public Law 116-94, enacted December 20,

[Python-Dev] Re: Windows buildbots may be broken

umaran Sent: Tuesday, August 3, 2021 09:29 To: Jason R. Coombs Cc: python-dev@python.org Subject: Re: [Python-Dev] Windows buildbots may be broken On Fri, Jul 30, 2021 at 02:28:08PM +, Jason R. Coombs wrote: > If you run such a buildbot, please consider running this command on >

[Python-Dev] Windows buildbots may be broken

g this command on your repo to bypass the issue: git rm -r :/ ; git checkout HEAD -- :/ You may want to consider adding this command after every update to the repo to avoid the stale state. ___ Python-Dev mailing list -- python-dev@python.org To unsub

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

Related, `inspect.Parameter.annotation` is affected too, but at least this attribute is called `annotation` instead of `type`. I noticed this today with `multipledispatch` (though [reported](https://github.com/mrocklin/multipledispatch/issues/104) in 2019) and some other internal code, both usi

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

Hi, I have written some classes that represent immutable views on collections (see "immutable-views" package on Pypi). Currently, these view classes inherit from the abstract collection classes such as Mapping, Sequence, Set. However, they implement the read-only methods of dict, list and set,

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

is no reason to ever do anything else. I hope that makes sense. On Wed, Mar 3, 2021 at 7:32 PM Sven R. Kunze <mailto:srku...@mail.de>> wrote: Hey Irit, find my 3 answers below: On 03.03.21 13:17, Irit Katriel wrote: > Hi Sven, > > I like your

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Hey Irit, find my 3 answers below: On 03.03.21 13:17, Irit Katriel wrote: Hi Sven, I like your formatting suggestion, thanks. I will do something like that. You're welcome. I'm not sure I understand your question. ExceptionGroup is a subclass of Exception (which is a subclass of BaseExce

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Hey Irit, cool proposal. I just have two questions regarding "except Exception" or "except BaseException" as it is used e.g. by concurrent.futures.process (def _process_worker) from the stdlib. Almost similarly, I maintain a library using this pattern to wrap/unwrap exceptions from remote P

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

very issue with existing code. Once that is clear, it should be easy for everybody to apply the same pattern to their code. Here is the copy from github: try:     r = call_item.fn(*call_item.args, **call_item.kwargs) except BaseException as e:     exc = _ExceptionWithTraceback(e, e.__tra

[Python-Dev] Re: Comments on PEP 558

Hi Mark, On 04.02.21 12:47, Mark Shannon wrote: Hi Sven, On 04/02/2021 9:06 am, Sven R. Kunze wrote: As long as it is possible to **write** to existing keys to **add new keys** to frame.f_locals, I am actually quite happy. Out of interest, why would you want to add new keys to the locals of

[Python-Dev] Re: Comments on PEP 558

On 03.02.21 23:37, Nick Coghlan wrote: No, PEP 558 doesn't remove it, it enhances it to be a live view of the frame state instead of an inconsistently updated snapshot. As long as it is possible to **write** to existing keys to **add new keys** to frame.f_locals, I am actually quite happy.

[Python-Dev] Re: Comments on PEP 558

Hi Mark, I've been working on a project heavily relying on frame.f_locals. Are you planning to remove it? On 30.01.21 13:18, Mark Shannon wrote: Given that f_locals is broken, why is keeping compatibility for this obscure, and probably unused case worthwhile? The break in compatibility wi

[Python-Dev] Re: [python-committers] [RELEASE] Python 3.8.1rc1 is now available for testing

I think I missed the announcement of the cutoff date for 3.8.1; I was hoping to get some bug fixes in for importlib.metadata. These aren’t crucial bugfixes, but it would be nice not to have them linger for months. Would you consider including these,

[Python-Dev] (no subject)

-- في 8 سبتمبر ، 2017 في تمام الساعة 12:30 بعد منتصف الليل ، سيقوم Masayuki YAMAMOTO < ma3yuki.8mamo10 at gmail.com > كتب: > *مرحبا يا قوم، * > > *I إرسال PEP 539 المسودة الثالثة للالنهاية. شكرا لجميع النصائح * > *وا

Re: [Python-Dev] Examples for PEP 572

On 04.07.2018 21:18, Steven D'Aprano wrote: Read the Appendix to the PEP: https://github.com/python/peps/blob/master/pep-0572.rst Yes, I did after I realized where that example came from. But my point was actually to understand the evaluation order because Uncle Timmy won't be around to expla

Re: [Python-Dev] Examples for PEP 572

Sorry for adding yet another mail. :-( On 04.07.2018 10:54, Serhiy Storchaka wrote: Sorry, this PEP was rewritten so many times that I missed your Appendix. while total != (total := total + term):     term *= mx2 / (i*(i+1))     i += 2 return total This very example here caught my eye. Is

Re: [Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

On 24.04.2018 11:21, Victor Stinner wrote: I have been asked to express myself on the PEP 572. +1 I knew about the relationship between read and write. But your stance on debugging just makes it a thing. Thanks a lot! ___ Python-Dev mailing list Py

Re: [Python-Dev] PEP 572: Assignment Expressions

On 25.04.2018 01:19, Steven D'Aprano wrote: Sorry, gcd(diff, n) is not the "perfect name", and I will tell you that sometimes g is better. [...] We were talking about the real-world code snippet of Tim (as a justification of := ) and alternative rewritings of it without resorting to new synta

Re: [Python-Dev] PEP 572: Assignment Expressions

On 23.04.2018 23:41, Tim Peters wrote: Why? "Give the result of an expression a name" is already heavily used in Python - it's just that the _contexts_ in which it can be done are very limited now. Which is a good thing IMO. It keeps stuff simple to reason about. At least to me, the objective

Re: [Python-Dev] PEP 572: Assignment Expressions

On 23.04.2018 23:19, Barry Warsaw wrote: I also think it effectively solves the switch-statement problem: if (get_response() as answer) == 'yes': do_it() elif answer == 'no': skip_it() elif answer == 'maybe' okay_then() That’s Pythonic enough for jazz! Is it just me or since wh

Re: [Python-Dev] PEP 572: Assignment Expressions

On 23.04.2018 22:37, Chris Angelico wrote: Ah, are you one of those programmers who writes code once and it's instantly perfect? I apologize, I didn't realize I was in the presence of a unicorn. Wow, constructive. Nothing is perfect, but if you don't consider your surroundings when doing chang

Re: [Python-Dev] PEP 572: Assignment Expressions

On 23.04.2018 19:31, Tim Peters wrote: Surely you're joking. This is math.gcd(), which is expensive for multi-thousand bit integers, and the interpreter knows nothing about it. Adding a cache of _any_ kind (LRU or otherwise) would make it even slower. Alright, if that problem is just about perf

Re: [Python-Dev] PEP 572: Assignment Expressions

On 23.04.2018 19:24, Chris Angelico wrote: On Tue, Apr 24, 2018 at 3:13 AM, Sven R. Kunze wrote: diff = x - x_base if diff and gcd(diff, n) > 1: return gcd(diff, n) # or if (x - x_base) and gcd(x - x_base, n) > 1: return gcd(x - x_base, n) and have the interpreter hand

Re: [Python-Dev] PEP 572: Assignment Expressions

On 23.04.2018 17:59, Steve Holden wrote: While Tim's expression might look (superficially) like C, the five-line alternative isn't exactly an inspiring example of Pythonicity, is it? What about diff = x - x_base if diff and gcd(diff, n) > 1: return gcd(diff, n) # or if (x - x_base)

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

On 21.12.2017 11:22, Terry Reedy wrote: @dataclass class C: a: int # integer field with no default b: float = 0.0 # float field with a default And the types will be recognized by type checkers such as mypy. And I think the non-typed examples should go first in the docs. I still

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 23.11.2017 08:38, Ivan Levkivskyi wrote: I think this code should be just equivalent to this code     def g():     temp = [(yield i) for i in range(10)]     return (v for v in temp) Semantics of the comprehension should be clear here (just an equivalent for-loop without name leaking

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

Isn't yield like a return? A return in a list/dict/set comprehension makes no sense to me. So, +1 on SyntaxError from me too. Cheers. On 22.11.2017 21:29, David Mertz wrote: Inasmuch as I get to opine, I'm +1 on SyntaxError. There is no behavior for that spelling that I would find intuitive

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

I agree with Steve. There is *cognitive* overhead to type annotations. I find that they make Python code harder to read and understand. So I object to them in the documentation and docstrings as well. (Note: while I agree that the notation is compact for the simple types, the fact that it would

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

+1 from me too. On 04.11.2017 21:55, Jim Baker wrote: +1, as Guido correctly recalls, this language guarantee will work well with Jython when we get to the point of implementing 3.7+. On Sat, Nov 4, 2017 at 12:35 PM, Guido van Rossum > wrote: This sounds reasona

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

On 03.11.2017 21:34, Paul Moore wrote: Consider someone who's downloaded Python and PyCharm (or Visual Studio). They want to get the benefit of the IDE code completion facilities, so they declare their argument as List[int], following the information they've found on how to declare lists of integ

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

Thanks for the PEP! :) I like the naming. ;) Though, I would like to add to Michel's argument in favor of a base class. On 11.09.2017 08:38, Michel Desmoulin wrote: - I read Guido talking about some base class as alternative to the generator version, but don't see it in the PEP. Is it still

Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)

Why not adding both? Properties do have their uses as does __getattr__. Cheers, Sven On 13.09.2017 11:43, Larry Hastings wrote: On 09/12/2017 12:38 AM, Larry Hastings wrote: On 09/11/2017 07:22 PM, Guido van Rossum wrote: The prototype is linked to from the PEP; for your convenience

Re: [Python-Dev] PEP 548: More Flexible Loop Control

On Wed, 06 Sep 2017 09:43:53 -0700, Guido van Rossum wrote: > I'm actually not in favor of this. It's another way to do the same thing. > Sorry to rain on your dream! So it goes :) I learned things by going through the process, so it wasn't wasted time for me even if (or because) I made several

Re: [Python-Dev] PEP 548: More Flexible Loop Control

On Wed, 06 Sep 2017 15:05:51 +1000, Chris Angelico wrote: > On Wed, Sep 6, 2017 at 10:11 AM, R. David Murray > wrote: > > I've written a PEP proposing a small enhancement to the Python loop > > control statements. Short version: here's what feels to me like a >

[Python-Dev] PEP 548: More Flexible Loop Control

I've written a PEP proposing a small enhancement to the Python loop control statements. Short version: here's what feels to me like a Pythonic way to spell "repeat until": while: break if The PEP goes into some detail on why this feels like a readability improvement in the

[Python-Dev] Version and Last-Modified headers are no longer required in PEPs.

The Version and Last-Modified headers required by PEP1 used to be maintained by the version control system, but this is not true now that we've switched to git. We are therefore deprecating these headers and have removed them from PEP1. The PEP generation script now considers them to be optional.

Re: [Python-Dev] PEP 550 v4

On 26.08.2017 19:23, Yury Selivanov wrote: ChainMap is constrained to be a Mapping-like object, but I get your point. Let's see what others say about the "lookup()". It is kind of an experiment to try a name and see if it fits. I like "get" more. ;-) Best, Sven PS: This might be a result o

Re: [Python-Dev] PEP 550 v4

On 26.08.2017 04:19, Ethan Furman wrote: On 08/25/2017 03:32 PM, Yury Selivanov wrote: A *context variable* is an object representing a value in the execution context. A new context variable is created by calling the ``new_context_var()`` function. A context variable object has two methods:

Re: [Python-Dev] API design: where to add async variants of existing stdlib APIs?

On 07.03.2017 19:37, Jelle Zijlstra wrote: 2017-03-07 10:15 GMT-08:00 Ethan Furman >: On 03/07/2017 09:41 AM, Brett Cannon wrote: I don't think a common practice has bubbled up yet for when there's both synchronous and asynchronous versions of a

Re: [Python-Dev] GitHub migration scheduled for Friday

On 09.02.2017 00:03, Victor Stinner wrote: 2017-02-08 23:42 GMT+01:00 Brett Cannon : Don't forget we are doing squash merges, Ah, I didn't know. Why not using merges? Same question here. I see no benefit just overhead, mistakes and longer processes. Sven _

Re: [Python-Dev] re performance

On 26.01.2017 22:33, Vlastimil Brom wrote: Hi, I can't speak about the details of mrab's implementation, but using regex, I get the resulting match instantly: [...] Nice! I focused on the stdlib re module as this is mainly used by other frameworks (like Django). (I personally prefer to use

[Python-Dev] re performance

Hi folks, I recently refreshed regular expressions theoretical basics *indulging in reminiscences* So, I read https://swtch.com/~rsc/regexp/regexp1.html However, reaching the chart in the lower third of the article, I saw Python 2.4 measured against a naive Thompson matching implementation.

Re: [Python-Dev] Generator objects and list comprehensions?

On 25.01.2017 07:28, Joe Jevnik wrote: That was a long way to explain what the problem was. I think that that solution is to stop using `yield` in comprehensions because it is confusing, or to make `yield` in a comprehension a syntax error. Same here; mixing comprehensions and yield (from)

Re: [Python-Dev] Imports with underscores

Interesting to see that others have the same problem. We also had this kind of "over-protective" behavior. As far as I know, our devs stopped doing it as it feels cumbersome. Another argument for this is: when using PyCharm, this IDE will suggest imports from those modules which aren't the o

Re: [Python-Dev] Possibly inconsistent behavior in re groupdict

- but I also appreciate the point about breaking code.  (Including mine, which has a comment on it that says, "match.groupdict returns a dict with str keys in Python 3.5" :D) Cheers, Gordon -Original Message- From: Guido van Rossum Reply-to: gu...@python.org To: Gordon R. B

[Python-Dev] Possibly inconsistent behavior in re groupdict

I've been lurking for a couple of months, working up the confidence to ask the list about this behavior - I've searched through the PEPs but couldn't find any specific reference to it. In a nutshell, in the Python 3.5 library re patterns and search buffers both need to be either unicode or byte st

Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

On 13.09.2016 20:21, Tres Seaver wrote: *Lots* of library authors have to straddle Python versions: consumers of those libraries only get to pick and choose when their code is at the "leaf" of the dependency tree (the application). Maybe, I didn't express myself well but this was not my intende

Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

On 13.09.2016 19:59, MRAB wrote: The recommended way of dealing with features across different versions of Python is to check for them and see if they raise NameError or whatever, but I wonder if there would be any benefit to recording such things somewhere, e.g. sys.features['ordered_args'] re

Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

On 11.09.2016 01:41, Nathaniel Smith wrote: I feel like I'm missing something here... by this reasoning, we should *never* change the language spec when new features are added. E.g. if people use async/await in 3.5 then their code won't be compatible with 3.4, but async/await are still part of th

Re: [Python-Dev] A Pseudo-Post-Mortem (not dead yet) on my Multi-Core Python Project.

Thanks for the post. :) There's some typo in the title and url. :/ :D On 07.09.2016 01:56, Eric Snow wrote: I'm not anticipating much discussion on this, but wanted to present a summary of my notes from the project I proposed last year and have since tabled. http://ericsnowcurrently.blogspot.co

Re: [Python-Dev] Do PEP 526 type declarations define the types of variables or not?

Didn't Koos say this works more like an expression annotation? IMO, the type of the expression is what is specified but the type of the variable can change over time (as you demonstrated). Sven PS: thinking this way, the new syntax is actually confusing as it annotates the variable not the

Re: [Python-Dev] Please reject or postpone PEP 526

Hi Mark, I agree with you about postponing. Not so much because of the issues you mentioned. Those all seem resolvable to me and mostly concerns type checkers, linters and coding styles not Python itself. However, I also don't like the rushing through as if this beta were the only chance to g

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

Thanks Guido, also to the rest of the PEP team (4 people) :) On 30.08.2016 23:20, Guido van Rossum wrote: I'm happy to present PEP 526 for your collective review: https://www.python.org/dev/peps/pep-0526/ (HTML) https://github.com/python/peps/blob/master/pep-0526.txt (source) There's also an i

Re: [Python-Dev] PEP 525

On 24.08.2016 21:05, Yury Selivanov wrote: Sorry for making you irritated. Please feel free to remind me about any concrete changes to the PEP that I promised to add on python-ideas. I'll go and re-read that thread right now anyways. No problem as it seems I wasn't the only one. So, it doesn

Re: [Python-Dev] PEP 525

On 24.08.2016 21:00, Yury Selivanov wrote: For an async generator there are two cases: either it tries to yield another value (the first time this happens you can throw an error back into it) or it tries to await -- in that case you can also throw an error back into it, and if the error comes

Re: [Python-Dev] PEP 525

On 24.08.2016 18:35, Guido van Rossum wrote: On Wed, Aug 24, 2016 at 8:17 AM, Yury Selivanov mailto:yselivanov...@gmail.com>> wrote: On 2016-08-23 10:38 PM, Rajiv Kumar wrote: I was playing with your implementation to gain a better understanding of the operation of asend()

Re: [Python-Dev] The devguide is now hosted on GitHub

Thanks a lot. :) On 22.07.2016 22:04, Brett Cannon wrote: https://github.com/python/devguide I have also moved all issues over as well and hooked up Read The Docs so that there's a mirror which is always up-to-date (vs. docs.python.org/devguide which is on

Re: [Python-Dev] Debugging Python scripts with GDB on OSX

On Wed, 06 Jul 2016 16:14:34 -, Alexandru Croitor wrote: > I'm interested to find out if debugging Python scripts with GDB is supported > on OSX at all? > > I'm referring to the functionality described on > https://wiki.python.org/moin/DebuggingWithGdb and on > http://fedoraproject.org/wi

Re: [Python-Dev] Request for CPython 3.5.3 release

On 03.07.2016 16:39, Guido van Rossum wrote: Another thought recently occurred to me. Do releases really have to be such big productions? A recent ACM article by Tom Limoncelli[1] reminded me that we're doing releases the old-fashioned way -- infrequently, and with lots of manual labor. Maybe we

Re: [Python-Dev] Our responsibilities (was Re: BDFL ruling request: should we block forever waiting for high-quality random bits?)

I also think it’s a great module for providing defaults that we can’t provide in os.urandom, like the number of bytes that are considered “secure” [1]. What I don’t think is that the secrets module means that all of a sudden os.urandom is no longer an API that is primarily used in a security se

Re: [Python-Dev] Why does base64 return bytes?

On Wed, 15 Jun 2016 11:51:05 +1200, Greg Ewing wrote: > R. David Murray wrote: > > The fundamental purpose of the base64 encoding is to take a series > > of arbitrary bytes and reversibly turn them into another series of > > bytes in which the eighth bit is not significant.

Re: [Python-Dev] Why does base64 return bytes?

On Tue, 14 Jun 2016 14:05:19 -0300, "Joao S. O. Bueno" wrote: > On 14 June 2016 at 13:32, Toshio Kuratomi wrote: > > > > On Jun 14, 2016 8:32 AM, "Joao S. O. Bueno" wrote: > >> > >> On 14 June 2016 at 12:19, Steven D'Aprano wrote: > >> > Is there > >> > a good reason for returning bytes? > >>

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On 10.06.2016 21:17, Donald Stufft wrote: On Jun 10, 2016, at 3:05 PM, David Mertz > wrote: OK. My understanding is that Guido ruled out introducing an os.getrandom() API in 3.5.2. But would you be happy if that interface is added to 3.6? It feels to me like the c

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On Thu, 09 Jun 2016 13:12:22 +0100, Cory Benfield wrote: > The Linux kernel can’t change this stuff easily because they mustn’t > break userspace. Python *is* userspace, we can do what we like, and we I don't have specific input on the rest of this discussion, but I disagree strongly with thi

Re: [Python-Dev] Proper way to specify that a method is not defined for a type

For those interested in this topic, if you are not already aware of it, see also http://bugs.python.org/issue25958, which among other things has a relevant proposed patch for datamode.rst. On Tue, 07 Jun 2016 10:56:37 -0700, Guido van Rossum wrote: > Setting it to None in the subclass is the inte

Re: [Python-Dev] FIXED: I broke the 3.5 branch, apparently

On Fri, 03 Jun 2016 23:21:25 +0100, MRAB wrote: > On 2016-06-03 22:50, R. David Murray wrote: > > I don't understand how it happened, but apparently I got a merge commit > > backward and merged 3.6 into 3.5 and pushed it without realizing what > > had happened. If

[Python-Dev] I broke the 3.5 branch, apparently

I don't understand how it happened, but apparently I got a merge commit backward and merged 3.6 into 3.5 and pushed it without realizing what had happened. If anyone has any clue how to reverse this cleanly, please let me know. (There are a couple people at the sprints looking in to it, but the m

Re: [Python-Dev] Adding Type[C] to PEP 484

On 15.05.2016 19:30, Guido van Rossum wrote: Right. I still have no good intuition for what Type[BasicUser, ProUser] would mean so I think you should be required to use the Union, which is clear. Type[] should only allow one parameter. Type[A, B] reminds me of isinstance(obj, (A, B)). Sven _

Re: [Python-Dev] file system path protocol PEP

On 13.05.2016 18:43, Chris Angelico wrote: https://docs.python.org/3/c-api/unicode.html#c.PyUnicode_Check https://docs.python.org/3/c-api/unicode.html#c.PyUnicode_CheckExact Thanks for pointing me at this. I searched via github and found usages only: https://github.com/python/cpython/search?u

Re: [Python-Dev] file system path protocol PEP

On 13.05.2016 17:29, Brett Cannon wrote: Purposeful change. It was what I had in my head after I posted my "groups" breakdown email and what Guido suggested as well independently. This helps alleviate any perf worries as type checks in C are pointer checks that are cheap to make compared to att

Re: [Python-Dev] file system path protocol PEP

On 13.05.2016 11:48, Koos Zevenhoven wrote: This issue is coupled with the future optimization questions. AFAIC coupling API design to optimization is called premature optimization. However, the proposed semantics will change if the checks are swapped. So, my actual question is: Is that an i

Re: [Python-Dev] file system path protocol PEP

new fspath semantics to the PEP. While I hope Brett is asleep in his time zone, I'm guessing he will agree (just saying this because you write "@Brett"). -- Koos On Fri, May 13, 2016 at 10:58 AM, Sven R. Kunze wrote: On 12.05.2016 18:24, Guido van Rossum wrote: def fspath(p: U

Re: [Python-Dev] file system path protocol PEP

On 12.05.2016 18:24, Guido van Rossum wrote: def fspath(p: Union[str, bytes, PathLike]) -> Union[str, bytes]: if isinstance(p, (str, bytes)): return p try: return p.__fspath__ except AttributeError: raise TypeError(...) @Brett Would you think it makes sense t

Re: [Python-Dev] file system path protocol PEP

On 12.05.2016 19:27, Ethan Furman wrote: Maybe, but a bad idea for two reasons: 1) Reducing a str to the exact same str is silly; and, more importantly Finding something silly is no technical argument. Best, Sven ___ Python-Dev mailing list Python-D

Re: [Python-Dev] file system path protocol PEP

On 12.05.2016 18:56, Ethan Furman wrote: On 05/12/2016 09:26 AM, Sven R. Kunze wrote: str and bytes will receive the __fspath__ attribute when this PEP is accepted? No, they won't. The __fspath__ protocol will reduce the rich path object down to a str/bytes object. Would this mak

Re: [Python-Dev] file system path protocol PEP

On 12.05.2016 17:42, Ethan Furman wrote: On 05/12/2016 01:31 AM, Sven R. Kunze wrote: I think the "Rationale" section ignores the fact the Path also supports the .path attribute now. Which indeed defines a common interface between path objects. The version of Python that has Pat

Re: [Python-Dev] file system path protocol PEP

On 11.05.2016 23:57, Brett Cannon wrote: On Wed, 11 May 2016 at 14:29 Nikolaus Rath > wrote: On May 11 2016, Brett Cannon mailto:br...@python.org>> wrote: > This PEP proposes a protocol for classes which represent a file system > path to be able to provi

Re: [Python-Dev] file system path protocol PEP

Thanks Brett for your hard work. My comments below: On 11.05.2016 18:43, Brett Cannon wrote: Rationale = Historically in Python, file system paths have been represented as strings or bytes. This choice of representation has stemmed from C's own decision to represent file system paths as

Re: [Python-Dev] file system path protocol PEP

On 12.05.2016 00:13, Brett Cannon wrote: I see this whole discussion breaking down into a few groups which changes what gets done upfront and what might be done farther down the line: 1. Maximum acceptance: do whatever we can to make all representation of paths just work, which means maki

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On 12.04.2016 18:04, Chris Barker wrote: On Tue, Apr 12, 2016 at 7:54 AM, Sven R. Kunze <mailto:srku...@mail.de>> wrote: My conclusion is that these changes are not optional and tweaking os, io and shutil is just yet another workaround for a clean solution. :) Is

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On 12.04.2016 16:59, Random832 wrote: Strings are strings. Paths are paths. That's were the difference is. Yes but why aren't these both "things that you may want to use to open a file"? Because "things that you may want to use to open a file" is a bit vague and thus conceal the fact that w

Re: [Python-Dev] pathlib - current status of discussions

Sorry for disturbing this thread's harmony. On 12.04.2016 08:00, Ethan Furman wrote: On 04/11/2016 10:14 PM, Chris Barker - NOAA Federal wrote: Consider os.path.join: Why in the world do the os.path functions need to work with Path objects? ( and other conforming objects) Because library

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On 12.04.2016 12:41, Paul Moore wrote: As your thoughts appear to have been triggered by my comments, I feel I should clarify. 1. I like pathlib even as it is right now, and I'm strongly -1 on removing it. 2. The "external dependency" aspect of 3rd party solutions makes them far less useful to m

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

, Apr 11, 2016, at 17:43, Sven R. Kunze wrote: So, I might add: 3. add more high-level features to pathlib to prevent a downgrade to os or os.path 3. reimplement the entire ecosystem in every walled garden so no-one has to leave their walled gardens. What's the point of batteries being includ

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On 11.04.2016 23:15, Ethan Furman wrote: We've pretty decided that we have two options: 1. remove pathlib 2. make the stdlib work with pathlib So we're trying to make option 2 work before falling back to option 1. If you have a way to make pathlib work with the stdlib that doesn't involve "fi

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On 11.04.2016 23:05, Random832 wrote: On Mon, Apr 11, 2016, at 16:48, Sven R. Kunze wrote: On 11.04.2016 22:33, Alexander Walters wrote: If there is headway being made, I do not see it. Funny that you brought it up. I was about posting something myself. I cannot agree completely. But starting

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On 11.04.2016 23:08, Random832 wrote: On Mon, Apr 11, 2016, at 17:04, Sven R. Kunze wrote: PS: The only way out that I can imagine is to fix pathlib. I am not in favor of fixing functions of "os" and "os.path" to except "path" objects; Why not? It occurred to

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On 11.04.2016 22:55, Alexander Walters wrote: Every conceivable way to fix pathlib have already been argued. Are any of them worth doing? Can we get consensus enough to implement one of them? If not, we should consider either dropping the matter or dropping the module. Right now, I don't se

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On 11.04.2016 22:33, Alexander Walters wrote: If there is headway being made, I do not see it. Funny that you brought it up. I was about posting something myself. I cannot agree completely. But starting with a comment from Paul, I realized that pathlib is something different than a string. Af

Re: [Python-Dev] pathlib+os/shutil feedback

On 10.04.2016 16:51, Paul Moore wrote: On 10 April 2016 at 15:07, Sven R. Kunze wrote: If there's some agreement to change things with respect to those 5 points, I am willing to put some time into it. In broad terms I agree with these points. Thanks for doing the research. It would cert

Re: [Python-Dev] Pathlib enhancments - method name only

On Sun, 10 Apr 2016 18:51:23 +1200, Greg Ewing wrote: > > On 9 April 2016 at 23:02, R. David Murray wrote: > > > >>That is, a 'filename' is the identifier we've assigned to this thing > >>pointed to by an inode in linux, but an os path is a text

[Python-Dev] pathlib+os/shutil feedback

I talked to my colleague. He didn't remember the concrete use-case, though, he instantly mentioned three possible things (no order of preference): 1) pathlib + mtime 2) os.walk and pathlib 3) creation/removal of paths He wasn't too sure but I checked with the docs and his memories seemed to b

Re: [Python-Dev] Pathlib enhancments - method name only

On Sat, 09 Apr 2016 17:48:38 +1000, Nick Coghlan wrote: > On 9 April 2016 at 04:25, Brett Cannon wrote: > > On Fri, 8 Apr 2016 at 11:13 Ethan Furman wrote: > >> On 04/08/2016 10:46 AM, Koos Zevenhoven wrote: > >> > On Fri, Apr 8, 2016 at 7:42 PM, Chris Barker wrote: > >> >> On Fri, Apr 8, 201

Re: [Python-Dev] Pathlib enhancments - method name only

On Fri, 08 Apr 2016 19:24:44 -, Brett Cannon wrote: > On Fri, 8 Apr 2016 at 12:10 Chris Angelico wrote: > > > On Sat, Apr 9, 2016 at 5:03 AM, Chris Barker > > wrote: > > > On Fri, Apr 8, 2016 at 11:34 AM, Koos Zevenhoven > > wrote: > > >> > > >> > > > >> > __pathstr__ # pathstring > > >> >

Re: [Python-Dev] When should pathlib stop being provisional?

06.04.2016 23:03, Ethan Furman wrote: On 04/06/2016 01:47 PM, Sven R. Kunze wrote: I still cannot remember what the concrete issue was why we dropped pathlib the same day we gave it a try. It was something really stupid and although I hoped to reduce the size of the code, it was less readable. But it

Re: [Python-Dev] Defining a path protocol

On 06.04.2016 22:55, Brett Cannon wrote: On Wed, 6 Apr 2016 at 13:54 Sven R. Kunze <mailto:srku...@mail.de>> wrote: Furthermore, we MIGHT later want some URI support, so I don't know off the top of my head if there's a difference between __fspath__ and __u

Re: [Python-Dev] Defining a path protocol

On 06.04.2016 22:28, Brett Cannon wrote: On Wed, 6 Apr 2016 at 13:20 Sven R. Kunze <mailto:srku...@mail.de>> wrote: What about __file_path__ Can be a directory as well (and you could argue semantics of file system inodes, beginners won't know the subtlety and/o

Re: [Python-Dev] When should pathlib stop being provisional?

On 06.04.2016 07:00, Guido van Rossum wrote: On Tue, Apr 5, 2016 at 9:29 PM, Ethan Furman wrote: [...] we can't do: app_root = Path(...) config = app_root/'settings.cfg' with open(config) as blah: # whatever It feels like instead of addressing this basic disconnect, th

  1   2   3   4   5   6   7   8   9   10   >