Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings
On 03/02/2018 07:30 PM, Chris Angelico wrote: On Sat, Mar 3, 2018 at 12:48 PM, Greg Ewing wrote: Chris Angelico wrote: It would NOT work for anything where the bool() of the desired object doesn't exactly match the loop's condition. while condition(x) where x = something(): ... And we're back to needing a new keyword. Though this is reasonably plausible, so I could add it to the PEP (as another rejected alternative) if there's support for it. So what happens to rejected alternatives when the PEP itself is rejected? ;) -- ~Ethan~ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings
On Sat, Mar 3, 2018 at 7:23 PM, Ethan Furman wrote: > On 03/02/2018 07:30 PM, Chris Angelico wrote: >> >> On Sat, Mar 3, 2018 at 12:48 PM, Greg Ewing wrote: >>> >>> Chris Angelico wrote: It would NOT work for anything where the bool() of the desired object doesn't exactly match the loop's condition. >>> >>> >>> >>> while condition(x) where x = something(): >>>... >>> >> >> And we're back to needing a new keyword. Though this is reasonably >> plausible, so I could add it to the PEP (as another rejected >> alternative) if there's support for it. > > > So what happens to rejected alternatives when the PEP itself is rejected? > ;) > Algebraically, they must be accepted. Right? ChrisA ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] An alternative to PEP 572's Statement-Local Name Bindings
On 3 March 2018 at 07:45, Nick Coghlan wrote: > On 3 March 2018 at 11:36, Greg Ewing wrote: >> >> 1. Name bindings local to an expression: >> >>roots = ([(-b-r)/(2*a), (-b+r)/(2*a)] where r = sqrt(b*b-4*a*c)) >> >> B. In an expression, surrounded by parentheses for >> disambiguation. Bindings are visible only within the >> parentheses. > > > I'll note that a significant benefit of this approach over the PEP 572 > approach is that it would be amenable to a comprehension style > scope-management solution: these expressions could create an implicitly > nested function and immediately call it, just as 3.x comprehensions do. > Adopting such an approach would *dramatically* lower the impact that hiding > the bindings from the surrounding scope would have on the overall name > resolution semantics. While I'm *still* not sure any of this provides enough benefit to be worth doing, I will say that this proposal feels far less complicated than PEP 572. I don't particularly like the extension to if and while statements (and it's been mentioned that there are remarkably few cases where the value you want to capture is the actual condition rather than a value the condition tests) but otherwise I'm OK with it (call me -0 on the proposal without if/while, and -0.5 on the if/while part). Paul ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] An alternative to PEP 572's Statement-Local Name Bindings
On Sat, Mar 03, 2018 at 02:36:39PM +1300, Greg Ewing wrote: >[(f(y), g(y)) for x in things where y = h(x)] > > Possible objections to this: > > * Requires a new keyword, which may break existing code. > > - Yes, but "where" is an unlikely choice of name, being > neither a noun, verb or adjective, so it probably wouldn't > break very *much* code. ``where`` is a very popular name in code related to SQL. Take for example ORMs: https://github.com/sqlobject/sqlobject/search?l=Python&q=where&type=&utf8=%E2%9C%93 https://github.com/zzzeek/sqlalchemy/search?l=Python&q=where&type=&utf8=%E2%9C%93 > -- > Greg Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] An alternative to PEP 572's Statement-Local Name Bindings
On 2018-03-03 08:09 AM, Oleg Broytman wrote: On Sat, Mar 03, 2018 at 02:36:39PM +1300, Greg Ewing wrote: [(f(y), g(y)) for x in things where y = h(x)] Possible objections to this: * Requires a new keyword, which may break existing code. - Yes, but "where" is an unlikely choice of name, being neither a noun, verb or adjective, so it probably wouldn't break very *much* code. ``where`` is a very popular name in code related to SQL. Take for example ORMs: https://github.com/sqlobject/sqlobject/search?l=Python&q=where&type=&utf8=%E2%9C%93 https://github.com/zzzeek/sqlalchemy/search?l=Python&q=where&type=&utf8=%E2%9C%93 [(lambda y: (f(y), g(y)))(h(x)) for x in things] ? -- Greg Oleg. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] An alternative to PEP 572's Statement-Local Name Bindings
Le 3 mars 2018 08:45, "Nick Coghlan" a écrit : On 3 March 2018 at 11:36, Greg Ewing wrote: > 1. Name bindings local to an expression: > >roots = ([(-b-r)/(2*a), (-b+r)/(2*a)] where r = sqrt(b*b-4*a*c)) > > B. In an expression, surrounded by parentheses for > disambiguation. Bindings are visible only within the > parentheses. > I'll note that a significant benefit of this approach over the PEP 572 approach is that it would be amenable to a comprehension style scope-management solution: these expressions could create an implicitly nested function and immediately call it, just as 3.x comprehensions do. Adopting such an approach would *dramatically* lower the impact that hiding the bindings from the surrounding scope would have on the overall name resolution semantics. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/ As I said, allowing this syntax (whether with a new keyword like 'where' or reusing something like 'with' to write print(y with y = x+1)) in any expression (not only after a "for" in a comprehension list) is useful only if a local scope is created (otherwise, it would be the same as simple assignement but in reverse ordre). One could see : print(y with y = x+1) As a shortcut for : print(next(y for y in [ x+1 ])) The same as this : [y for x in range(5) with y = x+1] being a shortcut for : [y for x in range(5) for y in [ x+1 ]] As said, allowing both use cases would lead to two different ways to write : [y for x in range(5) with y = x+1] vs [y with y = x+1 for x in range(5)] But that is not really an issue, it's logically different (is the y a conclusion of the iteration or a hidden lambda in the expression?). ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] An alternative to PEP 572's Statement-Local Name Bindings
On Sat, Mar 3, 2018 at 5:12 AM Oleg Broytman wrote: > On Sat, Mar 03, 2018 at 02:36:39PM +1300, Greg Ewing < > greg.ew...@canterbury.ac.nz> wrote: > >[(f(y), g(y)) for x in things where y = h(x)] > > > > Possible objections to this: > > > > * Requires a new keyword, which may break existing code. > > > > - Yes, but "where" is an unlikely choice of name, being > > neither a noun, verb or adjective, so it probably wouldn't > > break very *much* code. > > ``where`` is a very popular name in code related to SQL. Take for > example ORMs: > > > https://github.com/sqlobject/sqlobject/search?l=Python&q=where&type=&utf8=%E2%9C%93 > > > https://github.com/zzzeek/sqlalchemy/search?l=Python&q=where&type=&utf8=%E2%9C%93 > Where is also very common in numpy. So if someone did: from numpy import * data = where(condition) They might have issues > > -- > > Greg > > Oleg. > -- > Oleg Broytmanhttp://phdru.name/p...@phdru.name >Programmers don't die, they just GOSUB without RETURN. > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Class autoload
Hello everybody, I thought perhaps we could allow the usage of a "new" keyword to instanciate an object, ie: obj = new yourmodule.YourClass() In this case, it would behave the same as from yourmodule import YourClass; obj = YourClass(), except that it wouldn't need to be imported. This would also eliminate the need to manage an import list at the beginning of a script in most case. I'm really not proud of this idea but PHP has had autoload for years and when i open scripts with hundred lines of imports it makes me think Python could do something about this. Thanks in advance for your feedback Best regards -- ∞ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Class autoload
On 3/3/2018 12:12 PM, Jamesie Pic wrote: Hello everybody, I thought perhaps we could allow the usage of a "new" keyword to instanciate an object, ie: obj = new yourmodule.YourClass() I'd just do: import yourmodule obj = yourmodule.YourClass() Or as one line, if that's your thing: import yourmodule; obj = yourmodule.YourClass() Imports don't need to be at the top of the file. If you want to delay loading modules, that's fine. It's pretty cheap for an already loaded module. In my opinion it's not worth a new keyword and something else to learn. Eric In this case, it would behave the same as from yourmodule import YourClass; obj = YourClass(), except that it wouldn't need to be imported. This would also eliminate the need to manage an import list at the beginning of a script in most case. I'm really not proud of this idea but PHP has had autoload for years and when i open scripts with hundred lines of imports it makes me think Python could do something about this. Thanks in advance for your feedback Best regards -- ∞ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Class autoload
On Sun, Mar 4, 2018 at 4:12 AM, Jamesie Pic wrote: > > Hello everybody, > > I thought perhaps we could allow the usage of a "new" keyword to instanciate > an object, ie: > >obj = new yourmodule.YourClass() > > In this case, it would behave the same as from yourmodule import YourClass; > obj = YourClass(), except that it wouldn't need to be imported. This would > also eliminate the need to manage an import list at the beginning of a > script in most case. > This actually has nothing to do with classes. You can currently write this: import yourmodule obj = yourmodule.YourClass() without any sort of 'new' keyword. So presumably what you're asking for is a way to avoid typing the 'import' statement. That's something that's come up every once in a while. Usually for the benefit of throwaway scripts and the interactive interpreter, because in serious applications, a single 'import' line is a small price to pay for the clarity. You may want to dig through the archives to find the arguments for and against this sort of automated import. > I'm really not proud of this idea but PHP has had autoload for years and > when i open scripts with hundred lines of imports it makes me think Python > could do something about this. A hundred lines of imports? Surely an exaggeration... or possibly you have a whole lot of "from module import name" lines that could become a single "import module" line. Also, "PHP does this" is a terrible justification for a feature... :) ChrisA ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Class autoload
While i understand it would be harder to make it memory efficient, but this is python not go, and also this sort feature could be easily optional, also, it might even help against circular import issues, whoever hasn't imported a module from inside a function in their life may throw the first rock at my face (kidding) Yes i know it's sad php has this feature and python does not and again i'm not proud to say this but it's true. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Class autoload
On 03/03/2018 17:38, Eric V. Smith wrote: I'd just do: import yourmodule obj = yourmodule.YourClass() Or as one line, if that's your thing: import yourmodule; obj = yourmodule.YourClass() Which is More transparent: it's evident what the imported module is used for. More maintainable: you only need to add or remove one line or two adjacent lines per instance, instead of two widely separated lines. (as long as you're happy to defer the imports, of course). Regards Rob Cliffe ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Class autoload
On 3/3/2018 12:12 PM, Jamesie Pic wrote: Hello everybody, I thought perhaps we could allow the usage of a "new" keyword to instanciate an object, ie: obj = new yourmodule.YourClass() In this case, it would behave the same as from yourmodule import YourClass; obj = YourClass(), except that it wouldn't need to be imported. This would also eliminate the need to manage an import list at the beginning of a script in most case. If you really want this (untested): def autoload(mod, cls, *args, **kwargs): from mod import cls return cls(*args, **kwargs) obj = autoload(yourmodule, YourClass) -- Terry Jan Reedy ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 572: Statement-Local Name Bindings
On 03/02/2018 11:11 PM, Nick Coghlan wrote: On 3 March 2018 at 03:51, Ethan Furman wrote: Ah, right. Since the PEP primarily covers comprehensions, but then went on to discuss multi-line statements, I had forgotten the comprehension part. The answer is easy: assignment expressions in comprehensions stay inside comprehensions, just like other inner comprehension variables already do (function sub-scope, after all). Thank you for pointing that out. That wasn't the point I was try to make: my attempted point was that I see allowing an expression like "print((f() as x), x^2, x^3)" to overwrite the regular function local "x" as being just as unacceptable as "data = [x^2 for x in sequence]" overwriting it, and we already decided that the latter was sufficiently undesirable that we were willing to break backwards compatibility in order to change it. I think I explained myself poorly. I'm agreeing with you, and pointing out that the (var as expr) syntax /inside/ a comprehension would stay inside a comprehension, i.e. not leak out to locals(), just like your "x" above. -- ~Ethan~ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Class autoload
On 3/3/2018 2:33 PM, Terry Reedy wrote: On 3/3/2018 12:12 PM, Jamesie Pic wrote: Hello everybody, I thought perhaps we could allow the usage of a "new" keyword to instanciate an object, ie: obj = new yourmodule.YourClass() In this case, it would behave the same as from yourmodule import YourClass; obj = YourClass(), except that it wouldn't need to be imported. This would also eliminate the need to manage an import list at the beginning of a script in most case. If you really want this (untested): def autoload(mod, cls, *args, **kwargs): from mod import cls The make the above work with variables: import importlib # put at top of file mod = importlib.import_module(mod) cls = mod.getattr(cls) return cls(*args, **kwargs) obj = autoload(yourmodule, YourClass) -- Terry Jan Reedy ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] An alternative to PEP 572's Statement-Local Name Bindings
Robert Vanden Eynde wrote: One could see : print(y with y = x+1) As a shortcut for : print(next(y for y in [ x+1 ])) Or more straightforwardly, print((lambda y: y)(x + 1)) This is how the semantics of let-type constructs is often defined in lambda-calculus-inspired languages such as Scheme and Haskell, and it suggests a viable implementation strategy. -- Greg ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] An alternative to PEP 572's Statement-Local Name Bindings
Nathan Goldbaum wrote: Where is also very common in numpy. So if someone did: from numpy import * data = where(condition) They might have issues Bummer, I didn't know numpy used it. That puts rather a big dampener on the idea of making it a keyword. :-( Remaining options include: * Make it a keyword only in certain contexts. That's been done before, but only as a temporary measure. Making it a permanent feature seems a bit hackish, and could cause problems for syntax highlighters. * Pick another word that isn't used often. My next choice would be "given", with maybe "letting" as a distant third. (Not just "let", because it doesn't read right after the expression.) * Re-use another keyword. Here "with" seems to be the best choice, but that would entail giving it two wildly different meanings. Guido probably isn't going to like that, since he has already expressed disapproval of doing it with "for". Some people thought Wirth was mad when he made all the keywords in Modula upper-case, but maybe he knew a thing or two. Going back further, Algol required all keywords to be marked specially in some way (that was left up to the implementation). If I ever design another language, I think I'm going to require the source to be HTML, and insist that all keywords be bold. -- Greg ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Class autoload
Jamesie Pic wrote: obj = new yourmodule.YourClass() This would also eliminate the need to manage an import list at the beginning of a script in most case. I like the fact that I can usually tell what modules a module depends on by looking at the top for import statements. If people were encouraged to scatter implicit imports throughout the code, this would be much harder. Also, this seems a rather subtle and non-obvious distinction to make between two constructs that look like they should mean exactly the same thing. -- Greg ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Class autoload
On Sat, Mar 03, 2018 at 02:33:36PM -0500, Terry Reedy wrote:
> def autoload(mod, cls, *args, **kwargs):
> from mod import cls
> return cls(*args, **kwargs)
>
> obj = autoload(yourmodule, YourClass)
That won't work unless yourmodule and YourClass have already been
imported, since you'll get NameError.
You need to pass the names as strings, something like:
# also untested
def autoload(mod, cls, *args, **kwargs):
module = __import__(mod) # or use importlib
K = getattr(module, cls)
return K(*args, **kwargs)
obj = autoload('yourmodule', 'YourClass')
--
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Class autoload
On Sat, Mar 3, 2018 at 9:12 AM, Jamesie Pic wrote: > > Hello everybody, > > I thought perhaps we could allow the usage of a "new" keyword to instanciate > an object, ie: > >obj = new yourmodule.YourClass() > > In this case, it would behave the same as from yourmodule import YourClass; > obj = YourClass(), except that it wouldn't need to be imported. This would > also eliminate the need to manage an import list at the beginning of a > script in most case. The 'py' library has something like this for stdlib libraries. You could imagine extending it to handle arbitrary auto-imports, e.g. import auto_import as ai obj = ai.yourmodule.YourClass() The 'py' version never really caught on, but if you really like the idea there's nothing stopping you from implementing and using something similar today. -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Class autoload
On Sat, Mar 03, 2018 at 06:12:06PM +0100, Jamesie Pic wrote: > Hello everybody, > > I thought perhaps we could allow the usage of a "new" keyword to > instanciate an object, ie: > >obj = new yourmodule.YourClass() > > In this case, it would behave the same as from yourmodule import YourClass; > obj = YourClass(), except that it wouldn't need to be imported. Of course it would still need to be imported, it just wouldn't be imported *once* into the current module. So: a = new yourmodule.YourClass() b = new yourmodule.YourClass() c = new yourmodule.YourClass() d = new yourmodule.YourClass() would have to go through the process of importing yourmodule *four* times. Admittedly only the first time would be really expensive (and you can't escape that: this applies to `import` too), but the others won't be free. It will also break pickling. (I think.) There's also the serious cost of adding a new keyword, breaking everyone's code that uses "new" for something else. There has to be a good reason to do that, better than just "PHP offers this" or "I don't like managing imports". > I'm really not proud of this idea but PHP has had autoload for years and > when i open scripts with hundred lines of imports it makes me think Python > could do something about this. Somehow I don't feel that "hundreds of lines of imports" in a single script is realistic. Do you have an example of a publicly viewable script with hundreds of lines of imports? -- Steve ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] An alternative to PEP 572's Statement-Local Name Bindings
Robert Vanden Eynde wrote: But I think that the implementation of print(y with y = x + 1) would be more close to next(y for y in [ x+1 ]) WHy on earth should it be? Expanding that gives you a generator containing a loop that only executes once that is immediately run to yield exactly one value. Why bother with all that overhead? -- Greg ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] An alternative to PEP 572's Statement-Local Name Bindings
2018-03-03 8:40 GMT+01:00 Nick Coghlan : pairs = [(f(y), g(y)) for x in things with bind(h(x)) as y] I don't mucn like "with bind(h(x)) as y" because it's kind of like an abstraction inversion -- you're building something complicated on top of something complicated in order to get something simple, instead of just having the simple thing to begin with. If nothing else, it has a huge runtime cost for the benefit it gives. -- Greg ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] An alternative to PEP 572's Statement-Local Name Bindings
Robert Vanden Eynde wrote: The "make it a keyword in a context" might lead to things like "print(where where where = where)", not sure you'd want that :) What the heck, if it was good enough for PL/1... But that's just a choice of syntax, Choice of syntax is important, though. It's all very well to come up with an "insert syntax here" proposal that has some big obvious benefit, but if you can't actually come up with a pleasing syntax for it, then it won't fly. So it makes sense to consider potential syntaxes along with other aspects of a proposal. -- Greg ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Class autoload
On 03Mar2018 19:46, Jamesie Pic wrote: While i understand it would be harder to make it memory efficient, but this is python not go, and also this sort feature could be easily optional, also, it might even help against circular import issues, whoever hasn't imported a module from inside a function in their life may throw the first rock at my face (kidding) Yes i know it's sad php has this feature and python does not and again i'm not proud to say this but it's true. In a recent incarnation I spent a lot of time writing PHP. I've nothing good to say about it. However, to the "feature" point above: Its import facility is broken to the point iof being actively misleading. We weren't doing autoimports because it is good to be able to look at the top of a module and see what it uses. But even PHP's "use" statement is broken. It doesn't do anything until you access a name from it. _Then_ it goes to see if such a module exists. I blew a whole morning on this misbehaviour that didn't show unless a particular code path got to run. My personal belief is that the PHP people thought "this stuff runs on the fly per web page load, it needs to be fast fast fast!" And therefore their "use" statement just loads a string mapping of where to look for a name. The looking doesn't happen until the name gets used, if it gets used. So you can "use" a totally misspelt module and not realise it until very late in the game. We had a particularly skilled PHP guy on the team, and he and I still blew a couple of hours trying to figure out why one of my "use" statements didn't work, and that one _was_ due to some kind of autoimport magic I now forget. Personally, I'm -1 for an autoimport because it doesn't actually buy much, and -2 for any autoimport based on PHP semantics, which generally lead to "fail late" instead of "fail early". Cheers, Cameron Simpson ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
