Re: [Python-Dev] Is PEP 572 really the most effective way to solve the problems it's targeting?

Steven D'Aprano writes: > On Wed, Apr 25, 2018 at 09:36:31PM -0500, Ryan Gonzalez wrote: > > Now, what's the common theme here? **Declarations should be separate from > > expressions.** > > Declarations and assignments are not the same thing. Ryan mostly meant "initialization" rather than

Re: [Python-Dev] My fork lacks a 3.7 branch - can I create it somehow?

Tim Peters writes: > there is absolutely nothing "obvious" about source-control systems, > or workflows, before you already know them ;-) Obvious, adj.: More an expletive than a true adjective, shows a state of mind in which the speaker is comfortable that a statement fits her preconceptions.

[Python-Dev] PEP 484 (Type Hints) announcement

Mark Shannon writes: > Hello all, > > I am pleased to announce that I am accepting PEP 484 (Type Hints). Congratulations to all concerned! > Python is your language, please use type-hints responsibly :) +1 QOTW (not to mention ROTFLMAO) ___ Python

Re: [Python-Dev] Preserving the definition order of class namespaces.

Antoine Pitrou writes: > For some reason it sounds like we should be altruistic towards > people who are not :-) There's always a question of how far to go, of course, but one of the things I like about this community is the attention the developers give to others' pain. In that sense, I'm def

Re: [Python-Dev] time-based releases (was Re: Preserving the definition order of class namespaces.)

Nathaniel Smith writes: > DVCS back in the day :-). Unfortunately hg makes this a little > trickier than it could be, because in hg the same commit can't be in > two different branches; but this just means you have to insert some > no-op merges, oh well. Don't use named branches ("friends don

Re: [Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

Paul Moore writes: > In my environments, we frequently have ancient versions of RHEL > installed, sometimes with no Python at all (IIRC) or nothing better > than 2.4. That's pretty advanced as older Red Hat systems go. You're lucky it isn't 1.5.2! Getting serious, Red Hat systems have includ

Re: [Python-Dev] 2.7 is here until 2020, please don't call it a waste.

Antoine Pitrou writes: > On Sat, 30 May 2015 01:49:10 +0200 > Christian Heimes wrote: > > For performance patches we have to consider our responsibility for the > > environment. Every improvement means more speed and less power > > consumption. Python runs of hundreds of thousands of machines

Re: [Python-Dev] 2.7 is here until 2020, please don't call it a waste.

Antoine Pitrou writes: > > In a community of volunteers, ideology is typically a great > > motivator. > > If and only everyone agrees on it. That, my friend, is *your* ideology speaking. Some people work on open source to scratch technical itches -- the program doesn't do what they want, th

Re: [Python-Dev] Python 3 migration status update across some key subcommunities (was Re: 2.7 is here until 2020, please don't call it a waste.)

Florian Bruhin writes: > I think a big issue here is the lack of good newcomer tutorials for > Python 3. My business students (who are hardly advanced programmers) don't take tutorials seriously. They're way too focused on getting results. And there it's the "Doing with Python" books that ar

[Python-Dev] CRLF problems in repo

Rustom Mody writes: > Can submit a bug-report if it looks ok Thanks for the post. IMO this should have gone directly to the tracker because (1) you have some support for the idea that at least some of these are unintentional, and therefore candidates for alignment with the rest of the code, (2)

Re: [Python-Dev] CRLF problems in repo

Private, since it doesn't really have anything to do with evaluating actual content. FYI, this thread probably should have stayed on core-mentorship for a bit and then jumped directly to the tracker. Rustom Mody writes: > > because (1) you have some support for the idea that at least > > some

Re: [Python-Dev] PEP 493: Redistributor guidance for Python 2.7 HTTPS

Cross-posted to redirect discussion. Replies directed to Python-Ideas. Erik Bray writes on Python-Dev: > On Mon, Jul 6, 2015 at 6:21 AM, Antoine Pitrou wrote: > > On Mon, 6 Jul 2015 14:22:46 +1000, Nick Coghlan wrote: > >> > >> The main change from the last version discussed on python-ideas

Re: [Python-Dev] Freeze exception for http://bugs.python.org/issue23661 ?

Nick Coghlan writes: > I wonder: should we start putting some of these process details for > the different phases in the release PEPs themselves? Larry sent a good > summary to python-committers for 3.5 a while back, but they'd be > easier to find in the PEPs, and it would also make it clear w

[Python-Dev] Consenting adults considered beneficial [was: How far to go with user-friendliness]

Robert Collins writes: > What I am doing is rejecting the argument that because we can't fix > every mis-use users might make, we therefore should not fix the cases > where we can fix it. This involves a value judgment, every time a new fix is proposed, as to whether it's a mis-use that deserv

Re: [Python-Dev] Consenting adults considered beneficial [was: How far to go with user-friendliness]

Robert Collins writes: > I rejected an argument that just because some APIs are are > intrinsically able to be misused, that we should not try to write > better APIs. Well, at least to me what you wrote was inconsistent with that explanation of what you wanted to express: >> What I am doing

Re: [Python-Dev] How far to go with user-friendliness

Antoine Pitrou writes: > Frankly, this kind of inept discussion, I think you misunderstand what's going on. The people who advocate removal of a gratuitous special case may lack your perspective, but they're not incompetent to understand it. Specifically, you have a senior committer's perspect

Re: [Python-Dev] How far to go with user-friendliness

s.krah writes: > I don't think growing committer numbers is CPython's #1 problem. Maybe not; not being a committer I don't have a strong opinion myself. However, committers, and especially the group qualified for the BD1P role, regularly post wishes for more senior developers to these lists. >

Re: [Python-Dev] How far to go with user-friendliness

s.krah writes: > Sorry, that amounts to twisting my words. Let's not play the dozens here. That just extends the thread to no point. > It would be a great loss if he really stops and I hope he'll > reconsider. I agree with both points. I don't think anybody disagrees, so let's not belabor

Re: [Python-Dev] How far to go with user-friendliness

Terry Reedy writes: > Good (or certainly much better): this blank> I think so too, but IMO Nick and Antoine made a serious mistake by deprecating this as a "minor design decision" without further rationale. That's no excuse at all! The point of the Zen about "special cases" is that these mino

Re: [Python-Dev] How do we tell if we're helping or hindering the core development process? (was Re: How far to go with user-friendliness)

Ben Finney writes: > Definitely agreed, and I'm not implying otherwise. > > There is a distinction to be drawn: > > * If challenged to do so, could one (the contributor) present a > compelling justification for the change? Aside from Paul's disclaimer, this is way too high a bar. Nick

Re: [Python-Dev] How do we tell if we're helping or hindering the core development process? (was Re: How far to go with user-friendliness)

Nick Coghlan writes: > The draining and demotivating cases are the ones where *no new > information is introduced*, but the design decision is *challenged > anyway*. But this particular thread is an extreme case, that demonstrates why this kind of thing happens *despite* the good intentions of

Re: [Python-Dev] Status on PEP-431 Timezones

Paul Moore writes: > On 27 July 2015 at 15:57, Ronald Oussoren wrote: > > IMHO “+ 1 days” and “+ 24 hours” are two different things. Date > > arithmetic is full of messy things like that. “+ 1 month” is another > > example of that (which the datetime module punts completely > > and can be

Re: [Python-Dev] Status on PEP-431 Timezones

Terry Reedy writes: > On 7/27/2015 11:21 AM, MRAB wrote: > > > Also, if you "add one year" to 29 February 2016, what date do you get? > > I believe the 'conventional' answer is 1 March 2017. That is also 1 Mar > 2016 + 1 year. 1 March 2017 - 1 year would be 1 Mar 2016. Leap days > get

Re: [Python-Dev] Status on PEP-431 Timezones

Tres Seaver writes: > - From a human's perspective, "a day from now" is always potentially > unambigous, just like "a month from now" or "a year from now", whereas > "24 hours from now" is never so. I gather you've never been a prof who told a student with aggravated "writer's block" she had 2

Re: [Python-Dev] How do we tell if we're helping or hindering the core development process?

Ben Finney writes: > I've made a clear distinction between the need to *be able to* > justify a change, versus arbitrary demands to do so by arbitrary > members. > > The latter is what you're arguing against, and of course I agree. I've > never advocated that. Sure, but the former, when st

Re: [Python-Dev] Issues not responded to.

Xavier de Gaye writes: > > Here's a query: > > > > https://bugs.python.org/issue?@action=search&@columns=title,id,creator,activity,actor,status&@sort=activity&status=-1,1,3,4&message_count=1 > > > > This is nice, thanks. > Note that this is missing the cases where more than one message was

Re: [Python-Dev] PEP-498: Literal String Formatting

Barry Warsaw writes: > Besides, any expression you have to calculate can go in a local > that will get interpolated. Sure, but that style should be an application programmer choice. If this syntax can't replace the vast majority of cases where the format method is invoked on a literal string w

Re: [Python-Dev] PEP-498: Literal String Formatting

Barry Warsaw writes: > On Aug 17, 2015, at 11:02 AM, Paul Moore wrote: > > >print(f"Iteration {n}: Took {end-start) seconds") > > This illustrates (more) problems I have with arbitrary expressions. > > First, you've actually made a typo there; it should be > "{end-start}" -- notice

Re: [Python-Dev] Yet another "A better story for multi-core Python" comment

R. David Murray writes: > On Tue, 08 Sep 2015 10:12:37 -0400, Gary Robinson wrote: > > 2) Have a mode where a particular data structure is not reference > > counted or garbage collected. > > This sounds kind of like what Trent did in PyParallel (in a more generic > way). Except Gary has a

Re: [Python-Dev] PEP: Collecting information about git

Augie Fackler writes: > There is no sacrifice [for git users moving to Mercurial] other > than familiarity--and because Mercurial indeed has as simpler UI, > closing the familiarity gap from Git to Mercurial is much easier > than the other way around. AFAIK it is still much easier to do the k

Re: [Python-Dev] PEP: Collecting information about git

Nikolaus Rath writes: > Hmm, that's odd. As far as I know, the difference between the hg and git > DAG model can be summarized like this: > > * In git, leaves of the DAG must be assigned a name. If they don't have >a name, they will be garbage collected. You can turn off automatic garb

Re: [Python-Dev] PEP: Collecting information about git

Nikolaus Rath writes: > >> * hg named branches have no equivalent in git. > >> > >> Does that help? > > > > Well, that last bullet kind of complicates the model, doesn't it? :) > > Not if you come from git and want to use hg. You can just ignore > bookmarks. No, you cannot just ignor

Re: [Python-Dev] PEP: Collecting information about git

Nikolaus Rath writes: > On Sep 17 2015, "Stephen J. Turnbull" wrote: > > Nikolaus Rath writes: > > > > > Hmm, that's odd. As far as I know, the difference between the hg and git > > > DAG model can be summarized like this: > > >

Re: [Python-Dev] Proposing the deprecation of the pyvenv script

Barry Warsaw writes: > One thing that came up in a similar discussion is pip, and the > suggested move to `python -m pip`, which makes a lot of sense. > However, *inside* a virtualenv, there's no ambiguity about the > Python version associated with direct `pip` invocation, so it still > makes

Re: [Python-Dev] My collection of Python 3.5.0 regressions

Mark Lawrence writes: > I agree very strongly with your point here. Raising umpteen issues > over installation failures when a full release comes out strikes me > as below the belt when there have been multiple previous releases > without a squeak. Raising issues is always useful and appropr

Re: [Python-Dev] Proposing the deprecation of the pyvenv script

Terry Reedy writes: > Am I correct in guessing that on Windows, at least, R and Emacs do *not* > run in Command Prompt? I'm not sure what you mean by that. Of course they do run under Command Prompt, but the limitations of the command window are so severe that almost nobody ever does that, th

Re: [Python-Dev] PEP 0484 - the Numeric Tower

Chris Barker - NOAA Federal writes: > Laura Creighton writes: > > I merely worry about what happens if people > > start relying upon the fact that a float annotation 'will handle all > > the numbers I care about' to the forgotten Decimal users such as > > myself. > > Well, that's what you

Re: [Python-Dev] PEP 0484 - the Numeric Tower

Laura Creighton writes: > [W]hat I expect the type annotations to be used for, especially in > the SciPy world, is to make things easier for Numba to generate > fast code. I don't understand why that's a problem. *You* run mypy, and *you* decide whether to do anything about its warnings. The

Re: [Python-Dev] Support of UTF-16 and UTF-32 source encodings

Steve Dower writes: > Saying [UTF-16] is rarely used is rather exposing your own > unawareness though - it could arguably be the most commonly used > encoding (depending on how you define "used"). Because we're discussing the storage of .py files, the relevant definition is the one used by the

Re: [Python-Dev] Support of UTF-16 and UTF-32 source encodings

Laura Creighton writes: > Steve Turnbull, who lives in Japan, and speaks and writes Japanese > is saying that "he cannot see any reason for allowing non-ASCII > compatible encodings in Cpython". > > This makes me wonder. > > Is this along the lines of 'even in Japan we do not want such >

Re: [Python-Dev] Support of UTF-16 and UTF-32 source encodings

Random832 writes: > "Stephen J. Turnbull" writes: > > I don't see any good reason for allowing non-ASCII-compatible > > encodings in the reference CPython interpreter. > > There might be a case for having the tokenizer not care about encodings >

Re: [Python-Dev] Benchmark results across all major Python implementations

Stewart, David C writes: > Note: PGO is not the default way to build Python because it is > relatively slow to compile it that way. (I think it should be the > default). +1 Slow-build-fast-run should be the default if you're sure the optimization works. Only developers are likely to run a gi

Re: [Python-Dev] Request for pronouncement on PEP 493 (HTTPS verification backport guidance)

Nick Coghlan writes: > This is a significant rewrite that switches the PEP to a Standards > Track PEP proposing two new features for 2.7.12+: an > "ssl._verify_https_certificates()" configuration function, and a > "PYTHONHTTPSVERIFY" environment variable (although writing them > together like

Re: [Python-Dev] Request for pronouncement on PEP 493 (HTTPS verification backport guidance)

Nick Coghlan writes: > This is a significant rewrite that switches the PEP to a Standards > Track PEP proposing two new features for 2.7.12+: an > "ssl._verify_https_certificates()" configuration function, and a > "PYTHONHTTPSVERIFY" environment variable (although writing them > together like

Re: [Python-Dev] Python Language Reference has no mention of list comÃprehensions

Laura Creighton writes: > Am I missing something important about the 'display' language? A display is a constructor that looks like a literal but isn't. It is syntactically like the printed output, but may contain expressions to be evaluated at runtime as well as compile-time constant expressio

[Python-Dev] [OT] Without thinking! [was: Change the repr for datetime.timedelta]

Guido van Rossum writes: > (I was in a hurry and trying hard not to have to think :-). That makes me feel much better! There *are* things that *aren't* obvious, even to those born Dutch! :-) Happy Holidays! ___ Python-Dev mailing list Python-Dev@pyt

Re: [Python-Dev] New poll about a macro for safe reference replacing

Serhiy Storchaka writes: > This would be a voluntarism. You did due diligence, took the poll, and got additional information as well. It is *very* clear to me at least that you are paying full attention to the poll. Yes, the bikeshedding should end but I think you should do as you think best i

Re: [Python-Dev] PEP 509

Terry Reedy writes: > While I understand the rationale against __version__, it strikes me as a > better description of what it is, and easier on the brain than > __cache_token__. Maybe there is something even better, such as > __seqnum__. Or __generation__, as in "generational garbage col

Re: [Python-Dev] Devguide: Add a table summarizing status of Python branches

Emile van Sebille writes: > I'd prefer end-of-support -- bet you can't count how many pre 2.5 > installations are still live. I see your point, but (having just been thinking about CLAs and Schneier's blog) have to suggest that software that has an explicit "security support" period and is in

Re: [Python-Dev] Update PEP 7 to require curly braces in C

Zachary Ware writes: > It's quite surprising to me, since all (as far as I know) PEPs are > explicitly public domain. I am very much not a lawyer, though :) The reason for any explicit CLA is CYA: you can't be sure that the contributor DTRTs, so the CLA shows that the contribution was received

Re: [Python-Dev] do people use sys._mercurial?

francismb writes: > Does that helps traceability (reproducibility)? If distros use (?) > the tarball from the release why it doesn't have, at least, the > information from where that tarball was generated from (the check > out point) ? The pointer goes in the other direction: there will be a

Re: [Python-Dev] FAT Python (lack of) performance

INADA Naoki writes: > For example, http://benchmarksgame.alioth.debian.org/u64q/php.html > In Japanese, many people compares language performance by > microbench like fibbonacci. True enough. But as a teacher in a Japanese engineering school, I am ashamed to see that posted to a public list.

Re: [Python-Dev] FAT Python (lack of) performance

Nick Coghlan writes: > On 26 January 2016 at 17:16, Stephen J. Turnbull wrote: > > Our universities are doing an awful job at getting "big picture > > thinking" across to our students. > > That problem isn't specific to Japan - I'm not aware of *a

Re: [Python-Dev] FAT Python (lack of) performance

Terry Reedy writes: > On 1/26/2016 12:02 AM, INADA Naoki wrote: > > > People use same algorithm on every language when compares base language > > performance [1]. > > The python code is NOT using the same algorithm. The proof is that the > Python function will return the correct value fo

Re: [Python-Dev] FAT Python (lack of) performance

Terry Reedy writes: > So you agree that the limit of 39 is not intrinsic to the fib function > or its uses, but is an after-the-fact limit imposed to mask the bug > proneness of using substitutes for integers. I don't know what the limit used in the benchmark is, but it must be quite a bit l

Re: [Python-Dev] FAT Python (lack of) performance

Brett Cannon writes: > the core team has an implicit understanding that any performance > improvement is taken into consideration in terms of balancing > complexity in CPython with how much improvement it gets us. EIBTI. I can shut up now. Thank you!

Re: [Python-Dev] Opcode cache in ceval loop

Yury Selivanov writes: > Not sure about that... PEPs take a LOT of time :( Informational PEPs need not take so much time, no more than you would spend on ceval.txt. I'm sure a PEP would get a lot more attention from reviewers, too. Even if you PEP the whole thing, as you say it's a (big ;-) im

Re: [Python-Dev] Opcode cache in ceval loop

Nick Coghlan writes: > If someone else wanted to also describe the change in a PEP for ease > of future reference, using Yury's ceval.txt as input, I do think that > would be a good thing, but I wouldn't want to make the enhancement > conditional on someone volunteering to do that. I wasn't s

[Python-Dev] Licensing issue (?) for Frozen Python? [was: More optimisation ideas]

Executive summary: There is no licensing issue because Python isn't copyleft. Stick to the pragmatic *technical* issue of how to reliably provide corresponding source to those who want to look at that source (just because that's how we do things in Python). Emile van Sebille writes: > Except f

Re: [Python-Dev] Licensing issue (?) for Frozen Python? [was: More optimisation ideas]

Chris Angelico writes: > And even the GPL doesn't require you to distribute the source along > with every copy of the binary. As long as the source is *available*, > it's acceptable to distribute just the binary for convenience. True (and it would apply to frozen Python as long as the source i

Re: [Python-Dev] Google Summer of Code

As long as it's been brought up here: Yes, the PSF is applying. Google has been deliberately stirring things up in the last couple of years, so no promises, but it is very likely that we will be approved and core Python will have at least two slots allocated (although I'm not sure core Python eve

Re: [Python-Dev] Windows: Remove support of bytes filenames in the os module?

Chris Barker - NOAA Federal writes: > All I can say is "ouch". Hard to call it a regression to no longer > allow this mess... We can't "disallow" the mess, it's embedded in the lunatic computing environment (which I happen to live in). We can't even stop people from using existing Python progr

Re: [Python-Dev] Windows: Remove support of bytes filenames in theos module?

Steve Dower writes: > On 09Feb2016 1801, Andrew Barnert wrote: > > On Feb 9, 2016, at 17:37, Steve Dower > > wrote: > > > >> Could we perhaps redefine bytes paths on Windows as utf8 and use > >> Unicode everywhere internally? > > > > When you receive bytes fr

Re: [Python-Dev] Windows: Remove support of bytes filenames in theos module?

Executive summary: Code pages and POSIX locales aren't solutions, they're the Original Sin. Steve Dower writes: > On 09Feb2016 2017, Stephen J. Turnbull wrote: > > > The problem here is the protocol that Python uses to return > > > bytes paths, and that p

Re: [Python-Dev] Windows: Remove support of bytes filenames in theos module?

Victor Stinner writes: > It's annoying that 8 years after the release of Python 3.0, Python 3 > is still stuck by Python 2 :-( I prefer to think of it as the irritant that reminds me that I am very much alive, and so is Python, vibrantly so. ___ Pyth

Re: [Python-Dev] Windows: Remove support of bytes filenames in theos module?

Andrew Barnert via Python-Dev writes: > That doesn't mean the problem can't be solved. Apple solved their > equivalent problem, albeit by sacrificing backward compatibility in > a way Microsoft can't get away with. I haven't seen a MacRoman or > Shift-JIS filename since they broke the last hol

Re: [Python-Dev] Windows: Remove support of bytes filenames in theos module?

Executive summary: My experience is that having bytes APIs in the os module is very useful. But perhaps higher-level functions like os.scandir can do without (I present no arguments either way on that, just acknowledge it). Andrew Barnert writes: > Anyway, Windows CDs can't cause this problem.

[Python-Dev] Duelling PEPs not needed [was: PEP 515: Underscores in Numeric Literals]

Serhiy Storchaka writes: > I suspect that my arguments can be lost [without a competing PEP]. Send Georg a patch for his PEP, that's where they belong, since only one of the two PEPs could be approved, and they would be 95% the same otherwise. If he doesn't apply it (he's allowed to move it to

Re: [Python-Dev] Time for a change of random number generator?

Steven D'Aprano writes: > Peters has an opinion?) but if we do change, I'd like to see the > existing random.Random moved to random.MT_Random for backwards > compatibility and compatibility with other software which uses MT. Not > necessarily saying that we have to keep it around forever (a

Re: [Python-Dev] Hash randomization for which types?

Glenn Linderman writes: > I think hashes of all types have been randomized, not _just_ the list > you mentioned. Yes. There's only one hash function used, which operates on byte streams IIRC. That function now has a random offset. The details of hashing each type are in the serializations t

Re: [Python-Dev] Hash randomization for which types?

Christoph Groth writes: > Stephen J. Turnbull wrote: > > Yes. There's only one hash function used, which operates on byte > > streams IIRC. That function now has a random offset. The details of > > hashing each type are in the serializations to byte stream

Re: [Python-Dev] What does a double coding cookie mean?

Guido van Rossum writes: > > Should we recommend that everyone use tokenize.detect_encoding()? +1 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/optio

Re: [Python-Dev] What does a double coding cookie mean?

Glenn Linderman writes: > On 3/19/2016 8:19 AM, Serhiy Storchaka wrote: > > Therefore current CPython behavior can be correct, and the regular > > expression in PEP 263 should be changed to use greedy repetition. > > Just because emacs works that way (and even though I'm an emacs user), >

[Python-Dev] bugs.python.org email blockage at gmail

R. David Murray writes: > again. However, the IPV4 address has a poor reputation, and Verizon > at least appears to be blocking it. So more work is still needed. Don't take Verizon's policy as meaningful. Tell Verizon customers to get another address. That is the only solution that works fo

Re: [Python-Dev] thoughts on backporting __wrapped__ to 2.7?

Robert Collins writes: > Sadly that has the ordering bug of assigning __wrapped__ first and appears > a little unmaintained based on the bug tracker :( You can fix two problems with one patch, then! ___ Python-Dev mailing list Python-Dev@python.org h

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

Chris Angelico writes: > Outside of deliberate tests, we don't create files on our disks > whose names are strings of random bytes; Wishful thinking. First, names made of control characters have often been deliberately used by miscreants to conceal their warez. Second, in some systems it's al

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

Ethan Furman writes: > No, Stephen, that is not what this is about. Wrong Steven. Spelling matters in email too. And he's more worth paying attention to than I am. But I'll have my say anyway. ;-) > This is about the ugliness of code with str(path) this and > str(path) that -1 Not good en

Re: [Python-Dev] Defining a path protocol

Chris Barker writes: > which I suppose we do -- there are already other path implimentaitons out > there (though at least some are strings :-) ) Even so, their __fspath__ implementation might return syntactically canonicalized or realpath paths, rather than whatever is input. If cached and the

Re: [Python-Dev] Defining a path protocol

Ethan Furman writes: > It means the stuff in place won't change, but the stuff we're > adding now to integrate with Path will only support str (which is > one reason why os.path isn't going to die). I don't think this is a reason for keeping os.path. (Backward compatibility with existing code

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

Donald Stufft writes: > I think yes and yes [__fspath__ and fspath should be allowed to > handle bytes, otherwise] it seems like making it needlessly harder > to deal with a bytes path It's not needless. This kind of polymorphism makes it hard to review code locally. Once bytes get a foothol

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

Alexander Walters writes: > If there is headway being made, I do not see it. Filter out everything but the posts by Brett, and see if you still feel that way. (Other people have contributed[1], but that filter has about 20dB better S/N than the whole thread does.) Footnotes: [1] Brett may e

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

INADA Naoki writes: > > Why not print(obj)? print(obj) will give mojibake by default if sys.getfilenameencoding() != sys.getdefaultencoding(). > > str() is normal high-level API, and __fspath__ and os.fspath() should be > > low level API. > > Normal users shouldn't use __fspath__ and os.fspa

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

Nick Coghlan writes: > One possible way to address this concern would be to have the > underlying protocol be bytes/str (since boundary code frequently > needs to handle the paths-are-bytes assumption in POSIX), What "needs"? As has been pointed out several times, with PEP 383 you can deal wi

[Python-Dev] List posting custom [was: current status of discussions]

The following is my opinion, as will become obvious, but it's based on over a decade of observing these lists, and other open source development lists. In a context where some core developers have unsubscribed from these lists, and others regularly report muting threads with a certain air of asper

[Python-Dev] Pathlib enhancements - improve fsdecode and fsencode

Please please please, junk both "filter out bytes" proposals. Since they involve an exception, they impose an unnecessary "try" on all text applications that fear death on bytes returns. May as well just wrap all objects with __fspath__ in fsdecode, and all is happy. Counterproposal: make fsdeco

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

I was going to read the new posts that came in since I started this one (at one point it was 5X as long as it is now), but this thread is way out of control. My apologies to anybody who has presented[1] use cases in support of the wildly speculative proposals under discussion, but my bet is that t

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Nick Coghlan writes: > The use case for returning bytes from __fspath__ is DirEntry, so you > can write things like this in low level code: > > def myscandir(dirpath): > for entry in os.scandir(dirpath): > if entry.is_file(): > with open(entry) as f:

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Random832 writes: > On Thu, Apr 14, 2016, at 03:02, Stephen J. Turnbull wrote: > > I have a strong preference for str only, because I still don't see a > > use case for polymorphic __fspath__. > > Ultimately we're talking about redundancy and performance here.

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

Random832 writes: > And what such incompatibilities exist between bytes and str for the > purpose of representing file paths? A plethora of encodings. > At the end of the day, there's exactly one answer to "what file on > disk this represents (or would represent if it existed)". Nope. Supp

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Ethan Furman writes: > Substitute open() with sending those bytes somewhere else: Eg, pathlib.Path, which will raise? Surely it should be safe to pass a DirEntry to a pathlib constructor? Note that having Path call fsdecode implicitly is a bad idea, because we don't know the provenance of gene

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Nick Coghlan writes: > On 15 April 2016 at 00:52, Stephen J. Turnbull wrote: > > Nick Coghlan writes: > > > > > The use case for returning bytes from __fspath__ is DirEntry, so you > > > can write things like this in low level code: > &g

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Paul Moore writes: > On 16 April 2016 at 12:21, Stephen J. Turnbull wrote: > > OK, you win, __fspath__ needs to be polymorphic. > > > > But you've just shifted me to -1 on "os.fspath": it's an attractive > > nuisance. EIBTI, applications a

Re: [Python-Dev] PEP 8 updated on whether to break before or after a binary update

Victor Stinner writes: > Hum. > > if (width == 0 > and height == 0 > and color == 'red' > and emphasis == 'strong' > or highlight > 100): > raise ValueError("sorry, you lose") > > Please remove one space to vertically a

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Nick Coghlan writes: > str and bytes aren't going to implement __fspath__ (since they're > only *sometimes* path objects), so asking people to call the > protocol method directly for any purpose would be a pain. It *should* be a pain. People who need bytes should call fsencode, people who nee

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

I don't disagree with the basic analysis, but there are a number of issues with motivational statements. Koos Zevenhoven writes: > (B) "str-based only" > *Accept*: str, provided via __fspath__ as well as plain str. > *Return*: str. > *Audience*: relatively low-level code that works exclusivel

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Brett Cannon writes: > If we continue with the "str is an encoding of file paths", It's not. It's a representation, but not an encoding. In Python 3, encoding means a representation of a character string using bytes. It's using "encoding" generically for "representation" that makes your head h

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Brett Cannon writes: > On Mon, 18 Apr 2016 at 12:26 Stephen J. Turnbull wrote: > Well, it makes *your* head hurt; It doesn't, because I have a different (and IMHO better) model. I can interpret yours without pain by comparing to that. > By providing os.fspath() I can say

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Ethan Furman writes: > On 04/18/2016 12:25 PM, Stephen J. Turnbull wrote: > > Koos Zevenhoven writes: > > >> After all, we want something that's *almost* exclusively str. > > > > But we don't want that, AFAICT. Some clearly want this API to be

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Koos Zevenhoven writes: > On Tue, Apr 19, 2016 at 2:55 PM, Stephen J. Turnbull > wrote: > > > > AFAICS bytes return from __fspath__ is just YAGNI. Show me something > > that actually wants it. > > It might be, May I take that as meaning you just jumped to

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Brett Cannon writes: > Now if you can convince me that the use of bytes paths is very > minimal I doubt that I can do that, because all that Python 2 code is effectively bytes. To the extent that people are just passing it into their bytes-domain code and it works for them, they probably "port

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