Mailman 3 August 2015 - Python-ideas

Re: [Python-ideas] Forward-References & Out-of-order declaration
by Kale Kundert Aug. 29, 2015

Aug. 29, 2015

> On Wed, Aug 26, 2015 at 8:11 AM, Sven R. Kunze <srkunze(a)mail.de> wrote: > > The issue (not a huge problem again but annoying from time to time) is that > > the order of declaration in a module actually matters. IIRC other modern > > languages like C# don't require you do actually care about this anymore. > > > > Possible example (for whatever reason an author wants to do that -- also cf. > > stackoverflow): > > > > class UseThis(Base):… [View More]

3 2

pep-0484 - Forward references and Didactics - be orthogonal
by Prof. Dr. L. Humbert Aug. 28, 2015

Aug. 28, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, when looking at pep-0484 I find the *non-orthogonal* construction, which may lead to a misconcetion: What students should be able to code: 1. varinat #-------------wishful----------------------------------\ class Tree: def __init__(self, left: Tree, right: Tree): self.left = left self.right = right what students have to write instead: #-------------bad workaround----------------------------\ class Tree: def __init__(… [View More]

10 27

Draft2 PEP on string interpolation
by Mike Miller Aug. 28, 2015

Aug. 28, 2015

With the major design decisions made, behold version 2 of my draft PEP on string interpolation. It's now significantly shorter due to removal of most of the i18n related discussion, pruning, as well as simplification of the prose itself. I don't expect many changes from here on: https://bitbucket.org/mixmastamyk/docs/src/default/pep/pep-05XX.rst TL;DR: Here is a summary table and comparisons with my current understanding of the other proposals, please correct if they are now out … [View More]

7 22

Forward-References & Out-of-order declaration
by Sven R. Kunze Aug. 26, 2015

Aug. 26, 2015

While reading material for implementing some kind of import hooks and so forth for the xfork package, I came across this one: http://stackoverflow.com/questions/16907186/python-model-inheritance-and-or… Reactivated in my mind, after reading Prof. Humbert's request of adding a "more forwarded" referencing of classes, I just wanted to ask: 1) What is the general opinion regarding having a more declarative style when writing modules? 2) That given, what is the general opinion about … [View More]

4 4

Re: [Python-ideas] Draft PEP on string interpolation
by Paul Moore Aug. 25, 2015

Aug. 25, 2015

On 24 August 2015 at 23:04, Mike Miller <python-dev(a)mgmiller.net> wrote: > On 08/24/2015 02:54 PM, Paul Moore wrote: >> >> Agreed. In a convenience library where it's absolutely clear that a >> shell is involved (something like sarge or invoke) this is OK, but not >> in the stdlib as the "official" way to call external programs. > > Hmm, don't focus on os.system(), it could be any function, and not > particularly relevant, nor do I recommend this line … [View More]as the official way. Well, can you use an example that isn't misleading in its security implications? Specifically, I assumed from your use of os.system that you were proposing that the stdlib function (specifically in this case, a function that we've been trying to deprecate in favour of more secure alternatives for years) be updated to understand e-strings. > Remember Nick Coghlan's statement that the "easy way should be the right > way"? That's what this is trying to accomplish. But the right way is not to use os.system, so I don't *want* it to be easy. If you have a better example than running shell commands, please explain. (If your example is running full-blown shell syntax, rather than single commands, please give a more complicated example and we can let the debate explode into one about portability of shell constructs - but os.system to run a single command with a set of arguments is *wrong* and subprocess.Popen was created to replace it with a cross-platform, secure by default, solution). >> - People will fail to understand the difference between e'...' and >> f'...' and will use the wrong one when using os.system, and things >> will work correctly but with security vulnerabilities. > > > I don't recommend e'' and f'', only e'' at this moment. Then I'm strongly against this. As I've stated on a number of occasions, to me the crucial main use of any variation on this proposal is print(f"Iteration {n}: Duration {end-start}") If your e-string proposal works for this (via some consequence of implicitly calling str()) then it may still be on the cards - but the need for explicit str() calls in pathlib is a source of frustration there, so I'd like to be 100% sure that your proposal doesn't result in a need for explicit str() calls anywhere before accepting that e-strings can replace f-strings. By the way, the terminology in this thread (e-strings, f-strings, i-strings...) is dreadful. We need names that capture the essential differences (I've already proposed "format strings" for f-strings). Naming is important! Paul [View Less]

2 3

Re: [Python-ideas] Draft PEP on string interpolation
by Eric V. Smith Aug. 25, 2015

Aug. 25, 2015

On 08/24/2015 07:55 PM, Andrew Barnert wrote: > On Aug 24, 2015, at 08:14, Eric V. Smith <eric(a)trueblade.com> wrote: >> >>> On 08/23/2015 09:13 PM, Guido van Rossum wrote: >>> But for i-strings, I think it would be good if we could gather more >>> actual experience using them. Every potential use case brought up for >>> these so far (translation, html/shell/sql quoting) feels like there's a >>> lot of work needing to be done to see … [View More]if the idea is actually viable >>> there. It would be a shame if we added all the (considerable!) machinery >>> for i-strings and all we got was yet another way to do it >>> (https://xkcd.com/927/), without killing at least one competing approach >>> (similar to the way .format() has failed to replace %). >>> >>> It's tough to envision how we could gather more experience with >>> i-strings *without* building them into the language, but I'm really >>> hesitant to add them without more experience. (This is the "new on the >>> job market" paradox. :-) Maybe they could be emulated using a function >>> call that uses sys._getframe() under the covers? Or maybe it's possible >>> to cook up an experiment using other syntax hooks? E.g. the coding hack >>> used in pyxl (https://github.com/dropbox/pyxl).[1] >> >> >> I hope you don't mind that I borrowed the keys to the time machine. I'm >> using the implementation of _string.formatter_parser() that I added for >> implementing string.Formatter: > > Nifty! When I get a chance, I'll slap this together with an import hook using the untokenize hack, so I can actually play with i-strings (and f-strings) with the proposed syntax without needing a patch. If it looks good, I can write a real implementation that doesn't have all the untokenize problems, which could also eliminate the need for _getframe. (To make it backportable to 3.3/2.7 we'd still need to backport formatter_parser, right? But that still seems like something that could be done and posted on PyPI.) I don't know what the untokenize problems are, so I'm not sure I can help there. I also don't think I'd base any real implementation on _string.formatted_parser: it won't be terribly efficient. I've created a project on bitbucket: https://bitbucket.org/ericvsmith/istring where I'm playing with a "join" method and a callback interface, without ever exposing the looping and parsing to the caller. I think that would be a better interface than an iterator exposing the various parts of the string. But, as Guido suggests above, it's all just an academic exercise to understand how to best use i-strings. I suggest providing feedback on their API before implementing anything more serious. Eric. [View Less]

1 0

Re: [Python-ideas] Why does sys.flags have both .interactive and .inspect?
by MRAB Aug. 24, 2015

Aug. 24, 2015

On 2015-08-23 20:26, Alexander Walters wrote: > On 8/23/2015 15:20, MRAB wrote: > > Here's an answer on StackOverflow: > > > > http://stackoverflow.com/questions/1145428/difference-between-inspect-and-i… > > > That inspired this question. See, that answer talks about the internal > states of cpython. It does not answer if the flags actually can be > different at any given time (in my experimentation, they cannot), why > both are exposed to python users (… [View More]

3 3

Why does sys.flags have both .interactive and .inspect?
by Alexander Walters Aug. 23, 2015

Aug. 23, 2015

The sys.flags structure has both .interactive and .inspect for when python is run with -i. I cannot figure out a way to make one 'True' and the other 'False'. Are they both needed? Can one be removed? If they cannot be removed, and they can indeed be different values, can it be documented what the difference between them is?

2 1

all(iterable) should be like all(iterable, key=func)
by shiva prasanth Aug. 23, 2015

Aug. 23, 2015

functionality of all(iter) is to check all are true by converting it to boolean type if it is changed to all(iterable,key=lambda a:bool(a)) it still works and we can also do a lot of things like all([2,3,4],key=lamdba a:a) gives false above checks all are equal or not all([2,2,2],key=lambda a:a) gives true abouve checks all are equal or not all([1,2,4,9,key=lambda a:math.sqrt(a)**2==a]) and any(iter) should be changed as well

4 3

Re: [Python-ideas] PEP 448
by Adam Bartoš Aug. 22, 2015

Aug. 22, 2015

On Fri, Aug 21, 2015 at 9:47 PM, Balakrishnan Balasubramanian <balakrishnan.erode at gmail.com <https://mail.python.org/mailman/listinfo/python-ideas>> wrote: >* I tried out the new python3.5 rc1. I feel there is an inconsistency in *>* unpacking generalizations. *iterable is considered error but *iterable, *>* is a tuple. Should we make *iterable a list instead? This will be a *>* nice shortcut to expand an iterable? * That is no inconsitency. The fact that `*iterable,`… [View More]

1 0