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

Ethan Furman writes: > The part that you don't seem to acknowledge (sorry if I missed it) > is that there are str-like methods already on bytes. I haven't expressed myself well, but I don't much care about that. It's what Knuth would classify as a seminumerical method. What I do care about is

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

Glenn Linderman writes: > On 1/12/2014 4:08 PM, Stephen J. Turnbull wrote: >> Glenn Linderman writes: >>> the proposals to embed binary in Unicode by abusing Latin-1 >>> encoding. >> Those aren't "proposals", they are currently feasible >

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

Glenn Linderman writes: > On 1/13/2014 6:43 AM, Stephen J. Turnbull wrote: >> Glenn Linderman writes: >>> "smuggled binary" (great term borrowed from a different >>> subthread) muddies the waters of what you are dealing with. >> Not real

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

Greg Ewing writes: > I don't think of my viewpoint as being PBP. That term > assumes there is purity there to be beaten. To my mind, > any notion of purity with respect to bytes objects > went out the window as soon as it was given a pile > of text methods -- together with a text-like literal

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

Nick Coghlan writes: > "Give up" makes it sound like I got tired of arguing without being > convinced rather than admitting I was just plain wrong. I thought it was something in between (you explicitly said "lenient PEP 460" doesn't hurt you, but my understanding was you still believe that ther

Re: [Python-Dev] PEP 460 reboot

Guido van Rossum writes: > Of course, nobody in their right mind would use a format string > containing UTF-16 or EBCDIC. How about Shift JIS and Big 5 (traditionally "mandated by Microsoft" in their respective regions, with Shift JIS still overwhelmingly popular) and GB* ("GB18030 is not just

Re: [Python-Dev] magic method __bytes__

R. David Murray writes: > a file is a just a "wire" with an indefinite destination and > transmission time +1 QOTW Of course! "Store and ... wait for it ... forward" architecture 4-ever! Store and Forward, Inc. Since 1969. ___ Python-Dev mailing l

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

Steven D'Aprano writes: > I thought I understand the purpose of asciistr was exactly that, to > produce something that was compatible with both bytes and strings. asciistr *canonizes* something as an ASCII string, and therefore compatible with both bytes and str. It can't *create* such a thing

Re: [Python-Dev] PEP 460 reboot

> Right, that's the danger I was worried about, but the problem is that > there's at least *some* minimum level of ASCII compatibility that > needs to be assumed in order to define an interpolation format at all > (this is the point I originally missed). Only if you insist that bytes formats

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

Tres Seaver writes: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 01/15/2014 12:57 AM, Stephen J. Turnbull wrote: > > > asciistr *canonizes* something as an ASCII string, and therefore > > compatible with both bytes and str. It can't *cre

Re: [Python-Dev] PEP 460 reboot

Aside: OK, Guido, ya got me. I have a separate screed recounting the reasons for my apostasy, but that's probably not interesting any more. I'll send it to individuals on request. > But in terms of explaining the text model, that > separation is important enough that > > (1) We should

Re: [Python-Dev] PEP 460 reboot

Nick Coghlan writes: > Yes, I'm currently thinking the appropriate approach to the docs > will be to remove the current "these have most of the str methods > too" paragraph for binary sequences and instead create three > completely explicit lists of methods: > - provided, works with arbitr

Re: [Python-Dev] PEP 461 updates

Meta enough that I'll take Guido out of the CC. Nick Coghlan writes: > There are plenty of data formats (like SMTP and HTTP) that are > constrained to be ASCII compatible, "ASCII compatible" is a technical term in encodings, which means "bytes in the range 0-127 always have ASCII coded charact

Re: [Python-Dev] PEP 461 updates

Greg writes: > I don't think it matters whether the internal details of [the EIBTI > vs. PBP] debate make sense to the rest of us. The main thing is > that a consensus seems to have been reached on bytes formatting > being basically a good thing. I think some of it matters to the documentatio

Re: [Python-Dev] PEP 461 updates

Steven D'Aprano writes: > On Fri, Jan 17, 2014 at 11:19:44AM +0900, Stephen J. Turnbull wrote: > > "ASCII compatible" is a technical term in encodings, which means > > "bytes in the range 0-127 always have ASCII coded character semantics, > > do what

Re: [Python-Dev] Migration from Python 2.7 and bytes formatting

Neil Schemenauer writes: > I'd like to try porting code making use of the -2 feature to see how > helpful it is. The behavior is partway between Python 2.x laziness > and Python 3.x strictness in terms of specifying encodings. > > Python 2.x: > [...] > Python 3.x: > [...] The above are

Re: [Python-Dev] PEP 461 Final?

Nick Coghlan writes: > I also suggest introducing the phrase "ASCII compatible > segments in binary formats" somewhere, What is the use case for "ASCII *compatible* segments"? Can't you just say "ASCII segments"? I'm not sure exactly what PEP 461 says at this point, but most of the discussion

Re: [Python-Dev] Migration from Python 2.7 and bytes formatting

Neil Schemenauer writes: > That's it. After sleeping on it, I'm not sure that's enough Python > 2.x compatibility to help a lot. I haven't ported much code to 3.x > yet but I imagine the following are major challenges: > > - comparisons between str and bytes always returns unequal > > -

Re: [Python-Dev] PEP 461 Final?

Ethan Furman writes: > Well, that means that this PEP just further strengthens the notion > that format is for text (as then a custom numeric type could easily > override the display even for :d, :h, etc.) and % is for bytes > (where such glyphs are not natively representable anyway). This ar

Re: [Python-Dev] PEP 461 Final?

Ethan Furman writes: > > This argument is specious. > > I don't think so. I think it's a good argument for the future of > Python code. I agree that restricting bytes '%'-formatting to ASCII is a good idea, but you should base your arguments on a correct description of what's going on. It'

Re: [Python-Dev] Enable Hostname and Certificate Chain Validation

Cory Benfield writes: > I'm overwhelmingly, dramatically +1 on this. There's no good > architectural reason to not use the built-in certificate chains by > default. I'd like to be in favour of backporting this change to earlier > Python versions as well, but it feels just a bit too aggressive.

Re: [Python-Dev] Enable Hostname and Certificate Chain Validation

Donald Stufft writes: > As an additional side note, anecdotal evidence and what not, but > *every* time I bring this up somewhere I get at least one reply > that looks similar to > https://twitter.com/ojiidotch/status/425986619879866368 Hey, wait a cotton-picking minute! Are you telling me t

Re: [Python-Dev] Enable Hostname and Certificate Chain Validation

Wes Turner writes: > > But if it's only the already security-conscious developers and > > managers who go WTF?, and other environments don't do this by default, > > I'd consider that a "dangerous curve, slow down" sign. > > Mitigations: > > **Packaging** > > * Upgrade setuptools (dist

Re: [Python-Dev] The docstring hack for signature information has to go

Georg Brandl writes: > I don't think a well-chosen visible separator is worse off, such as "--\n". Don't you mean "-- \n"? L'Ancien Mail-guique-ly y'rs, ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python

Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError

M.-A. Lemburg writes: > IMO, it was a mistake to have None return a TypeError in > comparisons, since it makes many typical data operations > fail, e.g. I don't understand this statement. The theory is that they *should* fail. The example of sort is a good one. Sometimes you want missing va

Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final

Nick Coghlan writes: > I suspect everyone is also highly aware of the fact that there are > some ambitious changes in 3.4, Which is an argument for longer beta and RC periods than usual, or maybe some of the ambition should have been restrained. It's not necessarily a reason why more eyes help

Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final

Larry Hastings writes: > Someone could still inadvertently push those revisions back to > trunk, and then we'd have a real mess on our hands. Publishing > tarballs drops the possibility down to about zero. Note: I see no reason for you to change your process for the 3.4.0 release. I just wan

Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError

Greg Ewing writes: > Data retrieved from a database is often passed to other code > that has nothing to do with databases, and data received from > other code is inserted into databases. Somewhere in between > someone is going to have to be careful to translate back and > forth between Nones

Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final

Antoine Pitrou writes: > On Thu, 20 Feb 2014 10:24:16 +0900 > "Stephen J. Turnbull" wrote: > > > > The argument that a "read-only, no cherrypicking by committers" repo > > is nothing but a better tarball is valid, but as I say, AFAICS the > &g

Re: [Python-Dev] PEP 463: Exception-catching expressions

Ethan Furman writes: > On 02/21/2014 07:46 PM, Chris Angelico wrote: > > > > but not this: > > > > value = expr except Exception: default except Exception: default > > This should be the way it works. Nothing is gained in readability > by turning a try with multiple except statements into

Re: [Python-Dev] PEP 463: Exception-catching expressions

Steven D'Aprano writes: > On Fri, Feb 21, 2014 at 02:04:45PM -0500, Yury Selivanov wrote: > > > Inconvenience of dict[] raising KeyError was solved by > > introducing the dict.get() method. And I think that > > > > dct.get('a', 'b') > > > > is 1000 times better than > > > > dct['a'] e

Re: [Python-Dev] PEP 463: Exception-catching expressions

Antoine Pitrou writes: > Well, the only way to know that a key (or attribute) exists is to do > the lookup. What else would you suggest? Do the lookup at the C level (or whatever the implementation language is) and generate no exception, of course. That's what would make it possibly more effic

Re: [Python-Dev] PEP 463: Exception-catching expressions

Antoine Pitrou writes: > On sam., 2014-02-22 at 19:29 +0900, Stephen J. Turnbull wrote: > > Antoine Pitrou writes: > > > > > Well, the only way to know that a key (or attribute) exists is to do > > > the lookup. What else would you suggest? > >

Re: [Python-Dev] PEP 463: Exception-catching expressions

Antoine Pitrou writes: > On Sat, 22 Feb 2014 22:13:58 +1100 > Chris Angelico wrote: > > hasattr(x,"y") <-> (x.y or True except AttributeError: False) > But it's not the same. hasattr() returns a boolean, not an arbitrary > value. I think he meant hasattr(x,"y") <-> (x.y and True exce

Re: [Python-Dev] PEP 463: Exception-catching expressions

Antoine Pitrou writes: > Sure, but complaining about inefficiencies without asserting their > significance is not very useful. Since you completely missed the point of my post, I'll explain. I was in no way complaining about inefficiencies. My point was precisely the opposite: to the extent t

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 2

Glenn Linderman writes: > On 2/23/2014 2:25 PM, Antoine Pitrou wrote: >> On Sun, 23 Feb 2014 14:14:55 -0800 Glenn Linderman >> wrote: >>> On 2/23/2014 1:37 PM, Antoine Pitrou wrote: And you certainly*don't* print debugging output into a wire protocol. >>> Web server applications do,

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 2

Nick Coghlan writes that b'%a' is > the obvious way to interpolate representations of arbitrary objects > into binary formats that contain ASCII compatible segments. The only argument that I have sympathy for is > %a *should* be allowed for consistency with text interpolation although introd

Re: [Python-Dev] Python Remote Code Execution in socket.recvfrom_into()

Donald Stufft writes: > Instead of pre-generating one set of values that can be be used to > DoS things you have to pre-generate 256 sets of values and try them > until you get the right one. It’s like putting on armor made of > paper and saying it’s harder to stab you now. You obviously don'

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 2

Nick Coghlan writes: > sjt writes: > > although introduction of a new format character is a poor man's > > consistency, and this is consistency for consistency's sake. (I don't > > have a big problem with that, though. I *like* consistency!) > > It's *not* a new format character, unless y

Re: [Python-Dev] Start writing inlines rather than macros?

Skip Montanaro writes: > On Thu, Feb 27, 2014 at 1:23 PM, Antoine Pitrou wrote: > > Well, if we must maintain macros, let's maintain them everywhere and > > avoid the burden of two different implementations for the same thing. > > Would it be possible to generate the macro versions from the

Re: [Python-Dev] unicode_string future, str -> basestring, fix or feature

Terry Reedy writes: > On 3/2/2014 4:23 PM, Serhiy Storchaka wrote: > > Patches which add support for unicode strings were accepted for one > > issues (e.g. http://bugs.python.org/issue19099) and rejected for other > > issues (e.g. http://bugs.python.org/issue20014 and > > http://bugs.python.o

Re: [Python-Dev] unicode_string future, str -> basestring, fix or feature

> Guido van Rossum writes: > Given that the claim "Python 2 doesn't support Unicode filenames" > is factually incorrect (in Python 2.7, most filesystem calls in > fact do support Unicode, at least on some platforms), I don't understand what "support Unicode" means. Just that with ope

Re: [Python-Dev] Python 4: don't remove anything, don't break backward compatibility

Paul Moore writes: > I understand that - my concern is that people reading such comments > out of context might not realise this ("after all, that was what > Python 3000 meant, then you went and implemented it"). Sure, but why worry about it? The important part of "willful ignorance" is the "

Re: [Python-Dev] Whats New in 3.4 is pretty much done...

Christian Heimes writes: > But I don't want it to sound like an advert... Suggestions? Not to worry. It *can't* be an advert -- it's all true, and there are no irrelevant half-naked glistening bodies. (Former newts in the pond don't count.) Seriously, while "expect a clean build" is not "news

Re: [Python-Dev] Whats New in 3.4 is pretty much done...

Georg Brandl writes: > I think Chris meant he'd sound like an ad for Coverity. Oh, that. IIRC, we pay them nothing for the service. I know that they do it in part for commercial reasons and that it undoubtedly doesn't cost them a lot, but nonetheless it is a benefit that wouldn't hurt for ackn

Re: [Python-Dev] Python 3.5 now uses surrogateescape for the POSIX locale

Victor Stinner writes: > 2014-03-18 11:02 GMT+01:00 Atsuo Ishimoto : > > FYI: Guido was opposed to change error handler of stdin and > > stdout years ago. > > > > http://bugs.python.org/issue2630#msg65493 > > This issue proposes to use "backslashreplace" error handler for > stdout. This er

Re: [Python-Dev] Intricacies of calling __eq__

Kevin Modzelewski writes: > I think in this case, though, if we say for the sake of argument > that the guaranteed semantics of a dictionary lookup are zero or I don't understand the point of that argument. It's simply false that semantics are guaranteed, and all of the dunders might be user f

Re: [Python-Dev] Intricacies of calling __eq__

Kevin Modzelewski writes: > Sorry, I definitely didn't mean to imply that this kind of > optimization is valid on arbitrary subscript expressions; I thought > we had restricted ourselves to talking about builtin dicts. Ah, maybe so -- Maciej made that clear later for PyPy. My bad. (With the

[Python-Dev] PEP 466 (round 4): Python 2.7 network security enhancements

of the web as a whole. > > Christian and Donald Stufft also provided valuable feedback on a preliminary > draft of this proposal. > > Thanks also to participants in the python-dev mailing list threads [1,2,5]_ > > > References > == > >

[Python-Dev] PEP 466 (round 4): Python 2.7 network security enhancements

Urk. Premature send. As it turns out, I had no specific comments to make after the one comment on > Alternative: create and release Python 2.8 > -- My apologies to anybody who read to the bottom for wasting their time. I do have one generic comment on

Re: [Python-Dev] PEP 466 (round 4): Python 2.7 network security enhancements

Alex Gaynor writes: > Here's my proposed list of such featuers: And suppose that list grows over time? After all, it once was []. If we go for a feature-by-feature list, that has two more-or-less hidden costs. (1) Python-Dev has to specify which ones, and either risks a new specification deba

Re: [Python-Dev] collections.sortedtree

Nick Coghlan writes: > On 27 Mar 2014 07:02, "Guido van Rossum" wrote: >> Actually, the first step is publish it on PyPI, the second is to >> get a fair number of happy users there. The bar for getting something >> included into the stdlib is pretty high > The "why not a third party module

Re: [Python-Dev] On the necessity of PEPs [was "collections.sortedtree"]

Eli Bendersky writes: > On Wed, Mar 26, 2014 at 2:27 PM, Benjamin Peterson > wrote: >> I would have said that, too, several years ago, but I think we've >> been requiring (or using anyway) PEPs for a lot more things now. > YMMV but IMHO this is a good thing. FWIW I was just talking to Mat

Re: [Python-Dev] collections.sortedtree

Nick Coghlan writes: > On 27 March 2014 18:11, Stephen J. Turnbull wrote: > > I don't think it's ever really been resolved whether they're a > > "typical case that won't go away" or a special group whose > > special needs should be consid

Re: [Python-Dev] collections.sortedtree

Maciej Fijalkowski writes: > On Thu, Mar 27, 2014 at 10:11 AM, Stephen J. Turnbull > wrote: > > Maybe. That depends on if you care about the convenience of folks who > > have to get new modules past Corporate Security, but it's easier to > > get an upgrade o

Re: [Python-Dev] collections.sortedtree

Maciej Fijalkowski writes: > I just find "my company is stupid I find labeling companies as "stupid", merely because they are cautious about what external code they allow their developers to depend on, unacceptable. And I'll go to the trouble of explaining why. > so let's work around it by pu

Re: [Python-Dev] collections.sortedtree

Chris Angelico writes: > Don't forget, of course, that there is a middle ground. Something > that's really REALLY awesome on PyPI but isn't in the stdlib might be > packaged by various Linux distros. Oh, agreed, and any organization that cares that much will already have the RHEL or Ubuntu LTS

Re: [Python-Dev] collections.sortedtree

Tres Seaver writes: > On 03/27/2014 04:11 AM, Stephen J. Turnbull wrote: > > > Maybe. That depends on if you care about the convenience of folks > > who have to get new modules past Corporate Security, but it's easier > > to get an upgrade of the whole sheb

Re: [Python-Dev] collections.sortedtree

Tres Seaver writes: > I'm mostly arguing the FLOSS project You mean "a (mostly) volunteer-supported" FLOSS project, no? > should feel free to ignore Given the above qualification, you can put a period here, as far as I'm concerned. My question is "what does *Python* *want* to ignore?", not "

[Python-Dev] Language Summit notes

Guido van Rossum writes: > - We should make an effort to publicize that we're NOT sunsetting > Python 2.7 just yet; Maybe just add "Windows XP" to the SEO keywords for that page? Like *today* would be perfect timing. ___ Python-Dev mailing list Pyth

[Python-Dev] Appeal for reviews

I apologize for the tone. I need to go *right* now, and can't fix that. Really, I'm sympathetic and my goal is not just to defend python-dev, but to help you get the reviews your work deserves. Please read with that in mind. Steve Nikolaus Rath writes: > I've accumulated a number of patches i

Re: [Python-Dev] Appeal for reviews

Benjamin Peterson writes: > I don't think Nikolaus is wrong to post here. I often tell people that > sometimes the only way to get your patches in is to constantly poke us > about it. I admit the tone was biased toward nagging or "blaming the victim", and again I apologize for causing misunder

Re: [Python-Dev] Appeal for reviews

Janzert writes: > On 4/13/2014 2:36 AM, Stephen J. Turnbull wrote: > [snip] > > My claim is that in current circumstances, > > core-mentorship would be a more *effective* channel because > > > > - core-mentorship is *explicitly* for poking Those Who Can Help

Re: [Python-Dev] Appeal for reviews

Nikolaus Rath writes: > I've described the status of each bug in more detail in my reply > Terry, but generally all the issues contain a testcase (i.e., so I > consider them confirmed), do not require a PEP, contain a patch that > needs review and include documentation updates. I have signed

Re: [Python-Dev] Appeal for reviews

"Martin v. Löwis" writes: > Am 13.04.14 08:36, schrieb Stephen J. Turnbull: > > - core-mentorship is *explicitly* for poking Those Who Can Help > >(among other requests for help); > > It would be worth an experiment. I know that I wouldn't have rev

Re: [Python-Dev] Appeal for reviews

mar...@v.loewis.de writes: > For gaining commit access, it's really more important that the patch > is factually finished, than that it's author believes it to. If people > get it right the first time often enough, they get commit access. Yes, that's what I had in mind, but I guess I explained

Re: [Python-Dev] Python "2migr8"

Guido van Rossum writes: > On Mon, Apr 14, 2014 at 4:02 PM, Donald Stufft wrote: >> As someone who *has* given back, I can certainly understand why >> someone would feel that way. It often times *does* feel like >> CPython doesn’t want contributions. Sure, but most of the time that feeling

Re: [Python-Dev] Appeal for reviews

On 14 Apr 2014 08:42, "R. David Murray" wrote: >> Or to put it another way, I'd like to encourage contributors who >> want to get commit access to focus just as much on doing good >> reviews as they do on writing new patches. Currently the focus is >> all on getting patches accepted. >Huh,

Re: [Python-Dev] Mercurial sluggishness (was: this is what happens if you freeze all the modules required for startup)

Skip Montanaro writes: > "Instant" for me is "the blink of an eye," which Wikipedia reports as > typically between 100ms and 400ms. > If you blink, you've missed > Python 2.7 startup on a relatively modern machine. This is what I see for Mac OS X "Maverick

Re: [Python-Dev] Appeal for reviews

Terry Reedy writes: > On 4/15/2014 12:15 PM, Stephen J. Turnbull wrote: > > The only thing I don't like about it[3] is that it puts an > > explicit price on core developer time ("my time is worth 5x as > > much as yours"). > > Not really true

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

Guido van Rossum writes: > Does everyone involved know that "for x in d.iterkeys()" is > equivalent to "for x in d" and works the same in Python 2 and 3? [...] > This doesn't solve itervalues() and iteritems() but I expect those > are less common, and "for x, y in d.iteritems(): " is > rewr

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

Benjamin Peterson writes: > > I suppose there's no way to get the compiler to both make "for x in d" > > work as above, and make "for k, v in d" be equivalent to Python 2's > > "for k, v in d.iteritems()"? > That doesn't make sense. What if your keys are tuples? Oh, I still think it makes se

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

Greg Ewing writes: > Maybe what's wanted is a function analogous to enumerate() for > mappings instead of sequences. Picking a semi-arbitrary name > for now: > > for k, v in tabulate(d): I thought this already existed in six, though, with a name that is familiar to Python 2 programmers

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

Tres Seaver writes: > Re-adding features to make the strategy that works less painful is > just acknowledging that fact. Whether the strategy that works was anticipated is irrelevant, and the fact that pain *would* be involved was acknowledged all the way back to the days when "Python 3000" was

Re: [Python-Dev] List vs Tuple / Homogeneous vs Heterogeneous / Mutable vs Immutable

Leandro Pereira de Lima e Silva writes: >> In teaching Python, I find that analogs to other languages are >> helpful in explaining Python even if a person doesn't know the other >> language. >>    sorted(set(open(somefile))) >> is like: >>    cat somefile | sort | uniq       # different al

Re: [Python-Dev] pep8 reasoning

Chris Withers writes: > On 25/04/2014 04:03, Barry Warsaw wrote: > > I'd say it depends. If the code is going to be shared with > > people outside of your organization (e.g. open source libraries), > > then there's a strong motivation to be consistent throughout the > > community, which mean

Re: [Python-Dev] pep8 reasoning

Florent writes: > I wrote some words in the documentation, one year ago, to explain what > is the purpose of the tool and its limitations. There's no claim of > any endorsement implicit or explicit by the PSF, the PSU or any other > python developer :-) Of course there is an implicit claim of

Re: [Python-Dev] pep8 reasoning

Carl Meyer writes: > I'd like to thank Florent for taking the time to maintain an > extremely-useful tool that makes it feasible to keep to a > consistent PEP 8 style throughout a large codebase with many > contributors, I would too. N.B. Nick's complaints are a sort of left-handed complimen

Re: [Python-Dev] pep8 reasoning

Donald Stufft writes: > For instance there are things on PyPI named after websites, like > github, twitter, Facebook, etc. These things are not written by the > companies behind those websites and are merely written to interface > with those websites. Should we assume that those companies all

Re: [Python-Dev] pep8 reasoning

R. David Murray writes: > My unix fix-width terminal font handles most unicode (even a lot of > non-bmp stuff...though I have no idea if it is readable :). Oh, I bet you do. With a true fixed-width Unicode font, it's the *Latin-character* text that's painful, if not unreadable, because the asp

Re: [Python-Dev] pep8 reasoning

> On Mon, Apr 28, 2014 at 11:12 AM, Chris Barker wrote: > not really -- it allows it: > > # Aligned with opening delimiter. > foo = long_function_name(var_one, var_two, > var_three, var_four) > > but all the examples have more than one variable per line...my poi

Re: [Python-Dev] Python 2.7.7. on Windows

Mike Miller writes: > Microsoft's guidelines on where to install software are clear, and > don't make exceptions that "tools" should be installed to the root > of the drive to bypass file system permissions, for convenience. But there's the rub. In this case, Microsoft doesn't have *security*

Re: [Python-Dev] Python 2.7.7. on Windows

Steven D'Aprano writes: > On Tue, Apr 29, 2014 at 12:07:00PM +0900, Stephen J. Turnbull wrote: > > Note that if users actually paid attention to these guidelines, we'd > > be getting complaints from *them*, not from you. I don't recall ever > > seeing th

Re: [Python-Dev] Python 2.7.7. on Windows

Mike Miller writes: > However, this bug has been shitcanned for a decade. This is the > last chance to fix this bug in a branch that's going to be > supported until 2020! Probably. I'm not convinced. But that doesn't really matter. Your bigger concern is the deafening silence from the seni

Re: [Python-Dev] [Python-checkins] cpython: Remove the redundant and poorly worded warning message.

Nick Coghlan writes: > As you point out, most language development teams do very little to > try to educate their users about security issues. That's partly because it isn't going to be terribly effective. Security is a difficult subject, not one that's going to be usefully treated in a couple

Re: [Python-Dev] python process creation overhead

Gregory Szorc writes: > But the great many of us still on 2.7 likely won't see a benefit, > correct? How insane would it be for people to do things like pass -S > in the shebang and manually implement the parts of site.py that are > actually needed? Well, since it probably won't work Th

[Python-Dev] Updating turtle.py

Terry Reedy writes: > As to point 2, the source has been altered a bit (by others) but it is > not marked as such. How should it be? I would suggest adding """ Based on turtle 1.1b for Python 3.1 (4.5.2009) by Gregor Lingl. This is a revised version including changes from the Python community

Re: [Python-Dev] Language Summit Follow-Up

Chris Barker writes: > that way. Saying that their very first easy program is: > > print("hello world") > > is fine I have had similar experience on a small scale. Also I've been teaching R recently. The students who know Python (Python 3, we don't have backward compatibility issues in o

Re: [Python-Dev] Updating turtle.py

Raymond Hettinger writes: > One thing I would not like to see happen is telling interns that > their time is being well spent by pep-8 checking code in the > standard library. It sends that wrong message about what > constitutes an actual contribution to the core. There are plenty > of usef

Re: [Python-Dev] Updating turtle.py

Nick Coghlan writes: > Even if we had unlimited reviewer resources (which we don't), Raymond said "interns". We at least have a mentor. > There's a reason the desire to "throw it out and start again with a > clean slate" is a common trait amongst developers: You mean the Cascade of Attentio

Re: [Python-Dev] Internal representation of strings and Micropython

dw+python-...@hmmz.org writes: > Given the specialized kinds of application this Python > implementation is targetted at, it seems UTF-8 is ideal considering > the huge memory savings resulting from the compressed > representation, I think you really need to check what the applications are in

Re: [Python-Dev] Internal representation of strings and Micropython

Serhiy Storchaka writes: > It would be interesting to collect a statistic about how many indexing > operations happened during the life of a string in typical (Micro)Python > program. Probably irrelevant (I doubt anybody is going to be writing programmers' editors in MicroPython), but by far

Re: [Python-Dev] Internal representation of strings and Micropython

Glenn Linderman writes: > 3) (Most space efficient) One cached entry, that caches the last > codepoint/byte position referenced. UTF-8 is able to be traversed in > either direction, so "next/previous" codepoint access would be > relatively fast (and such are very common operations, even whe

Re: [Python-Dev] Internal representation of strings and Micropython

Paul Sokolovsky writes: > Please put that in perspective when alarming over O(1) indexing of > inherently problematic niche datatype. (Again, it's not my or > MicroPython's fault that it was forced as standard string type. Maybe > if CPython seriously considered now-standard UTF-8 encoding, re

Re: [Python-Dev] Internal representation of strings and Micropython

Serhiy Storchaka writes: > Yes, I remember. I thing that hybrid FSR-UTF16 (like FSR, but UTF-16 is > used instead of UCS4) is the better choice for CPython. I suppose that > with populating emoticons and other icon characters in nearest 5 or 10 > years, even English text will often contain

Re: [Python-Dev] Internal representation of strings and Micropython

Paul Sokolovsky writes: > That kinda means "string is atomic", instead of your "characters are > atomic". I would be very surprised if a language that behaved that way was called a "Python subset". No indexing, no slicing, no regexps, no .split(), no .startswith(), no sorted() or .sort(), ...!

Re: [Python-Dev] Moving Python 2.7 [was: 3.5] on Windows to a new compiler

Brian Curtin writes: > Adding features into 3.x is already not enough of a carrot on the > stick for many users. Intentionally leaving 2.7 on a dead compiler is > like beating them with the stick. No, it's like a New Year's resolution to stop self-flagellating, and handing the whip to the user

Re: [Python-Dev] why is not 64-bit installer the default download link for Windows?

Ivan Pozdeev via Python-Dev writes: > "One or more issues caused the setup to fail. Please fix the issues and > the retry setup. For more information see the log file . > > 0x80070661 - This installation package is not supported by this > processor type. Contact your product vendor." >

Re: [Python-Dev] [PEP 576/580] Comparing PEP 576 and 580

Antoine Pitrou writes: > We could proceed by consensus: the PEP author publicly proposes a PEP > delegate, and if no core developer opposes, that person is officially > accepted as delegate. I think this is too decentralized. I think there should be enthusiasm for the delegate, say two "secon

Re: [Python-Dev] make patchcheck and git path

Michael Felt (aixtools) writes: > When building out of tree there is no .git reference. If I > understand the process it uses git to see what files have changed, > and does further processing on those. Just guessing based on generic git knowledge here: If you build in a sibling directory of t

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