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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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

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

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

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"

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,

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

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(): ...