Mailman 3 August 2015 - Python-ideas

Re: [Python-ideas] Forward-References & Out-of-order declaration
by Kale Kundert 29 Aug '15

29 Aug '15

> 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): > > pass > > > > class UseThat(Base): > > pass > > > > class Base: > > pass > > > > In that regard, Python feels a bit rusty. > > Frankly, I don't have a problem with this. You get a mandate that > requires you to do what's good practice anyway: lay things out in a > logical order. In the same way that Python's use of indentation for > block structure is generally just enforcing what you'd have done > regardless of language, this requires that you sort things in > dependency order. That tends to mean that the first use of any name in > a module is its definition/source. Want to know what 'frobnosticate' > means? Go to the top of the file, search for it. > > Having that enforced by the language is a restriction, but how often > does good code have to be seriously warped to fit into that model? Not > often, in my experience. > > ChrisA Just to provide a concrete example, sqlalchemy's ORM seems to really contort itself (at least from the user's perspective) to get around this problem. The reason in that case is that the dependencies between tables don't have to be directed acyclic graphs, e.g. it's common for two tables to depend on each other. I've also run into this problem when working with my home-grown message-passing APIs, which can also form more complicated dependency graphs. So I do think that good code occasionally has to warp itself to fit into python's model. -Kale

3 2

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

28 Aug '15

-----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__(self, left: 'Tree', right: 'Tree'): self.left = left self.right = right / Please enable: from __future__ import annotations so the *first* variant should be possible \ At this very moment (python 3.5rc1), it is not possible, but we need it, so the construction will be orthogonal from the point of view for students(!) - _one_ concept should work in different circumstances. TNX Ludger Humbert - -- https://twitter.com/n770 http://ddi.uni-wuppertal.de/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlXam2MACgkQJQsN9FQ+jJ+RHgCfdcTgjVmZ3ULLwjerpJ3NdN7d NH8AoIvdTqWbkcfi7o8e7JuAYXbgZk0V =OMhU -----END PGP SIGNATURE-----

10 27

Draft2 PEP on string interpolation
by Mike Miller 28 Aug '15

28 Aug '15

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 of date: String Interpolation PEP Comparison =================================== ================= ================= ================= ================= PEP PEP 498 PEP 501 Draft PEP ================= ================= ================= ================= Name Format/f-string Gen. Purpose Str… Expression-string Prefix f'' i'' e'' Syntax str.format()+ .format+Template+ str.format()+ Returns String join expr… Object Object Immediate Render Yes No Yes Deferred Render No Yes, str, mutable Yes I18n Support No Yes Input available Escaping Hook No No Yes, manual ================= ================= ================= ================= The table can be found here and updated via pull-request: https://bitbucket.org/mixmastamyk/docs/src/default/pep/pep_comparison.rst -Mike

7 22

Forward-References & Out-of-order declaration
by Sven R. Kunze 26 Aug '15

26 Aug '15

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 introducing the out-of-order declaration asked for in the StackOverflow posts? Best, Sven

4 4

Re: [Python-ideas] Draft PEP on string interpolation
by Paul Moore 25 Aug '15

25 Aug '15

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 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

2 3

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

25 Aug '15

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 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.

1 0

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

24 Aug '15

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 (if they cannot be different, they > should be), or if they can be different, in what conditions they would be. > > That should be resolved through either getting rid of one (eventually), > or documentation. > I tested it, and they _can_ be different. sys.flags.interactive will be true if you include the -i switch. sys.flags.inspect will be true if you include the -i switch or set the PYTHONINSPECT environment variable. Thus, if you don't include the -i switch but _do_ set PYTHONINSPECT, sys.flags.interactive will be false and sys.flags.inspect will be true.

3 3

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

23 Aug '15

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 23 Aug '15

23 Aug '15

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š 22 Aug '15

22 Aug '15

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,` is a tuple has nothing to do with unpacking generalizations. It is a tuple, because it's a tuple literal. >>> *range(5), (0, 1, 2, 3, 4) >>> (*range(5),) (0, 1, 2, 3, 4) >>> (-1, *range(5), 5) (-1, 0, 1, 2, 3, 4, 5) >>> [-1, *range(5), 5] [-1, 0, 1, 2, 3, 4, 5] >>> [*range(5)] [0, 1, 2, 3, 4] >>> {*range(5)} {0, 1, 2, 3, 4} Regards, Adam Bartoš

1 0