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

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

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

Nick Coghlan writes: > The gist of the motivation for bytes/str polymorphism here is similar to > that for restoring __mod__ polymorphism in > https://www.python.org/dev/peps/pep-0461/: I don't think it is, actually. Filenames off the wire cannot be relied on to be in the local file system en

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

Eric Snow writes: > On Tue, Apr 19, 2016 at 10:50 AM, Brett Cannon wrote: > > Ah, but you see that doesn't make porting easy. > Perhaps I missed previous discussion on the point, but why not support > both __fspath__() -> str and __fssyspath__() -> bytes? That's fine by me, I can live with t

Re: [Python-Dev] Problemas con modulos

Guido van Rossum writes: > Thank you Facundo, and thanks for following up here! (I wonder if it > wouldn't have been just as efficient if you had just BCC'ed the list to > your original response? Or perhaps with a brief English note at the > top?) BCC'ing lists usually gets your post held, r

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

Chris Angelico writes: > AFAICT, the compatibility layer would simply decode the bytes using > surrogateescape handling, which should round-trip anything. By design. See PEP 383. Or rather, the OP should; he has not done his homework and is confused by his own FUD. This whole subthread is re

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

Greg Ewing writes: > Paul Moore wrote: > > On 13 May 2016 at 17:57, Ethan Furman wrote: > > > >>1) What is a wallet garden? > > > > I assumed he meant "walled garden" > > Works either way -- you'd want a wall around your wallet > garden to stop people stealing your wallets. Actually,

Re: [Python-Dev] Why does PEP 7/8 explicitly suggest 2 spaces after a period?

Bernardo Sulzbach writes: > > On 05/20/2016 09:27 AM, Brett Cannon wrote: > > > > The period is a full-stop punctuation mark, but visually obscure [1]. > > It is small. This does not make it hard to notice, however. That depends on fonts, and on the ability of the user to write correctly as

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

Sven R. Kunze writes: > Type[A, B] reminds me of isinstance(obj, (A, B)). Sure, but Guido already invoked EIBTI. For one (obscure) alternative, Type[A, B] reminded me of Fun(A,B) (the functors from category A to category B), and in Python I would tend to map that to a function type (taking argu

Re: [Python-Dev] Adding NewType() to PEP 484

Guido van Rossum writes: > But seriously I think we should just decide between Derived Type and > Distinguished Type [Alias]. I like "typedef", but I'm pretty sure it wouldn't carry the same connotations to people who aren't C programming oldtimers. I dislike "derived" because that fits stuff

Re: [Python-Dev] PEP 451 update

Nick Coghlan writes: > OK, time for me to stop trying to remember the details of the problem > I'm trying to solve and go look them up in the source code :) OMG! Even Nick does that. I feel better now! ;) ___ Python-Dev mailing list Python-Dev@pytho

Re: [Python-Dev] PEP 454 (tracemalloc) disable ==> clear?

Victor Stinner writes: > 2013/10/29 Jim Jewett : > > reset() function: > > > > Clear traces of memory blocks allocated by Python. > > > > Does this do anything besides clear? If not, why not just re-use the > > 'clear' name from dicts? > > (I like the reset() name. Charles-F

Re: [Python-Dev] PEP 454 (tracemalloc) disable ==> clear?

Jim Jewett writes: > Later, he wrote: > > I don't see why disable() would return data. > > disable is indeed a bad name for something that returns data. Note that I never proposed that disable() *return* anything, only that it *get* the trace. It could store it in some specified object, or

[Python-Dev] Restoring the aliases for the non-Unicode codecs

Nick Coghlan writes: > The long gory history in http://bugs.python.org/issue7475 took a > different turn earlier this year when I noticed > (http://bugs.python.org/issue7475#msg187698) that the codecs module > already *had* type neutral helper functions in the form of > codecs.encode and code

Re: [Python-Dev] Add transform() and untranform() methods

Walter Dörwald writes: > Am 15.11.2013 um 00:42 schrieb Serhiy Storchaka : > > > > 15.11.13 00:32, Victor Stinner написав(ла): > >> And add transform() and untransform() methods to bytes and str types. > >> In practice, it might be same codecs registry for all codecs just with > >> a new att

Re: [Python-Dev] py.ini documentation improvement

Nick Coghlan writes: > Turning my Windows gaming machine back to the default settings and > trying to bootstrap pip was one of the key things that got me > motivated to work on PEP 453. It still astounds me that one company > can both create Visual Studio, *and* make it difficult to configure

Re: [Python-Dev] Python 3 is five years old

Tim Peters writes: > I'm doing all my own coding in 3 now - I like it. I just wish someone > had told me in 2008 ;-) I think it's a testament to the basic strength of the language that you haven't noticed that *nothing has changed* in Python 2 for several years. ;-) __

[Python-Dev] Attribute docstrings [was: One-line abstractmethod function?]

Reply-To set to python-id...@python.org. Terry Reedy writes: > For data attributes, which are usually mutable, it should be attached to > the attribute *concept*, which is represented by the name, rather than > the current but usually changeable value. Values are usually already > document

Re: [Python-Dev] Add Gentoo packagers of external modules to Misc/ACKS

R. David Murray writes: > As far as we have been able to determine, Tae Wong is in fact a bot > (note the 'seo' in the email address...a tip of the hand, It's not a good idea to guess about foreign words, including names. "seo" is a common romanized spelling for a Korean syllable (or perhaps par

Re: [Python-Dev] How long the wrong type of argument should we limit (or not) in the error message (C-api)?

Steven D'Aprano writes: > That's a good point, but I think most coders would have a very fuzzy > idea of the difference between type(obj).__name__ and > obj.__class__.__name__, and when to use one versus the other. > Likewise, I think that most of the time it is useful to distinguish > be

Re: [Python-Dev] Fwd: Python 2.x and 3.x usage survey

Ron Adam writes: > * What is Python 4? "Due in 2025" (the next Year of the Snake). Happy New Year to all and best wishes for 2014! ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

Re: [Python-Dev] [RELEASED] Python 3.4.0b2

Bob Hanson writes: > On Sun, 5 Jan 2014 20:09:23 -0600, Tim Peters wrote: > > > As Benjamin asked, could you please flesh out what > > "blah-blah-blah-dot-com" means - what, exactly, was the site your > > firewall warned you about? > > Forgive me, but I'm an old man with very poor vision.

Re: [Python-Dev] [RELEASED] Python 3.4.0b2

Stephen J. Turnbull writes: > .deploy.static.akamitechnologies.com (according to host ), Ignore this; *my* aging eyes dropped the "A" in "akamAitechnologies.com". Sorry for the noise. ___ Python-Dev mailing list Pyth

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

Is this really a good idea? PEP 460 proposes rather different semantics for bytes.format and the bytes % operator from the str versions. I think this is going to be both confusing and a continuous target for "further improvement" until the two implementations converge. Nick Coghlan writes: >I

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

Daniel Holth writes: > Isn't it true that if you have bytes > 127 or surrogate escapes then > encoding to latin1 is no longer as fast as memcpy? Be careful. As phrased, the question makes no sense. You don't "have bytes" when you are encoding, you have characters. If you mean "what happens w

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

Benjamin Peterson writes: > I agree. This is a very important, much-requested feature for low-level > networking code. I hear it's much-requested, but is there any description of typical use cases? The ones I've seen on this list and on -ideas are typically stream-oriented, and seem like they

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

Antoine Pitrou writes: > However, interpolating a bytes object isn't out of place, and it is > what a minimal "formatting" primitive could do. Something like this? # VERY incomplete pseudo-code class str: # new method # fmtstring has syntax of .format method's spec, ma

Re: [Python-Dev] Python3 "complexity"

Kristján Valur Jónsson writes: > Still playing the devil's advocate: > I didn't used to must. Why must I must now? Did the universe just > shift when I fired up python3? No. Go look at the Economist's tag cloud and notice how big "China" and "India" are most days. The universe has been shi

Re: [Python-Dev] Python3 "complexity"

Ben Finney writes: > That's a much better analogy. The customer may not care, but the > question is essential and must be answered; if the supplier guesses what > the customer wants, they are doing the customer a disservice. It is a much better analogy for me on my desktop, and for programmers

Re: [Python-Dev] Python3 "complexity"

Paul Moore writes: > So I think that if this discussion is to be of any real benefit, a > specific example is needed. I honestly don't think I've ever > encountered a case where "Sometimes [I] just want to parse text > files" and code that uses the default encoding (i.e., looks pretty > much

Re: [Python-Dev] Python3 "complexity"

Steven D'Aprano writes: > If it were, we wouldn't need text strings :-) Speak for yourself, Kemosabe. Red man need Unicode, full meal not just a few bytes. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/pyt

Re: [Python-Dev] Python3 "complexity"

INADA Naoki writes: > latin1 is OK but is it Pythonic? Yes. EIBTI, including being explicit that you're doing something that has semantics that you are ignoring but may come back to bite you or somebody who naively uses your module. There's nothing un-Pythonic about using potentially dangerous

Re: [Python-Dev] Python3 "complexity"

Chris Angelico writes: > I'm not saying that chardet is bad, but I *am* saying, and I stand > by this, that an auto-detect option on file open is a bad idea. I have used it by default in Emacs and XEmacs since 1990, and I certainly haven't experienced it as a bad idea at *any* time in more than

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

M.-A. Lemburg writes: > I complete agree with Stephen, that bytes are in fact often > an encoding of text. If that text is ASCII compatible, I don't > see any reason why we should not continue to expose the C lib > standard string APIs available for text manipulations on b

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

MRAB writes: > > with open("outfile.pdf", "w", encoding="latin-1") as f: > > f.write(pdf) > > > [snip] > The second example won't work because you're forgetting about the > handling of line endings in text mode. Not so fast! Forgot, yes (me too!), but not work? Not quite: with o

Re: [Python-Dev] PEP 460: allowing %d and %f and mojibake

Georg Brandl writes: > > if it weren't for your stupid maximalist opposition). > > Can you please stop throwing personal insults around? You don't have to > resort to that level. Ethan's posts (as an example of one general trend in this thread) are pretty frustrating, you have to admit. MA

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

Daniel Holth writes: > -1 on adding more surrogateesapes by default. It's a pain to track > down where the encoding errors came from. What do you mean "by default"? It was quite explicit in the code I posted, and it's the only reasonable thing to do with "text data without known (but ASCII com

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

Steven D'Aprano writes: > then the name is horribly misleading, and it is best handled like this: > > content = '\n'.join([ > 'header', > 'part 2 %.3f' % number, > binary_image_data.decode('latin-1'), > utf16_string, # Misleading name, actually Unicode

Re: [Python-Dev] PEP 460: allowing %d and %f and mojibake

Ethan Furman writes: > Nothing else is ideal. I'll go that route if I have to. I > understand that in the real world you go with what works, but in > the development stage you fight for the ideal. :) You're going to lose, because Python 3 chose a different ideal that conflicts with yours.

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

Ethan Furman writes: > > This kind of subtlety is precisely why MAL warned about use of latin1 > > to smuggle bytes. > > And why I've been fighting Steven D'Aprano on it. No, I think you haven't been fighting Steven d'A on "it". You're talking about parsing and generating structured binary

Re: [Python-Dev] PEP 460: allowing %d and %f and mojibake

Glenn Linderman writes: > the proposals to embed binary in Unicode by abusing Latin-1 > encoding. Those aren't "proposals", they are currently feasible techniques in Python 3 for *some* use cases. The question is why infecting Python 3 with the byte/character confoundance virus is preferable t

Re: [Python-Dev] PEP 460: allowing %d and %f and mojibake

Ethan Furman writes: > 1) Are you saying it's okay to be insulting when frustrated? I >also find this mega-thread frustrating, but I'm trying >very hard not to be insulting. OK, no. Understandable, yes. > 2) If you are going to use my name, please be certain of the facts >[1].

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

Steven D'Aprano writes: > Of course you're right, but I have understood the above as being a > sketch and not real code. (E.g. does "header" really mean the literal > string "header", or does it stand in for something which is a header?) > In real code, one would need to have some way of te

Re: [Python-Dev] PEP 460: allowing %d and %f and mojibake

Ethan Furman writes: > On 01/12/2014 02:57 PM, Stephen J. Turnbull wrote: > > No, Nick's point is that there's no encoding needed there are all, > > just a bunch of methods that handle numbers in the range 0-255. You > > can rationalize the particular choice

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