Re: [Python-ideas] Class autoload

[Ethan Furman]

On 03/03/2018 10:46 AM, 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.


Not sad at all.  It's a misfeature that Python is better off without.

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

[Nick Coghlan]

On 4 March 2018 at 03:42, Chris Angelico  wrote:

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


Excessive numbers of top level imports in a single file are also frequently
a sign that that module has too many responsibilities and could stand to be
split up (either as multiple parallel APIs, or by splitting out a lower
level helper library) for ease of comprehension. Those split up API
implementations can then be aggregated back together into a single public
API (e.g. in a package `__init__.py` file)

As Chris has noted, function level lazy imports are also already supported,
and we've (begrudgingly) made the import system work harder to successfully
resolve circular imports in recent releases (they're also much harder to
dead lock in Python 3 than they were in Python 2, since we also switched
over to per-module import locks).

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/

Re: [Python-ideas] Class autoload

[Stephen J. Turnbull]

Jamesie Pic writes:

 > obj = new yourmodule.YourClass()

I don't understand what this is good for.  Keeping up with PHP is not
something that is a goal for Python.  Borrowing useful features is
definitely an idea, but you need to explain why it's useful.

I also don't understand why you call this "autoload", and claim it
avoids importing the module.  The "autoload" I'm familiar with from
Lisp is actually lazy loading: the object's name is marked as loadable
and from where, but the module is loaded only if the name is
dereferenced.  In most implementations, the whole module is imported,
as it is in Python.  Experience says that modules are generally
coherent, with lots of internal cross-references: you'll need the
whole thing eventually anyway.  I would guess this is true in PHP as
well, as it is a very dynamic language too AIUI.

Various barriers you'll need to clear:

(1) Niggle: "new" already means something in Python that is different
from initialization.  (class.__new__ vs. class.__init__)  You
*could* ignore that and use "new" for this feature anyway, but you
probably want to choose a different name.

(2) Adding keywords is *very* hard to do in Python, for several
non-technical reasons.  This is not going to clear the bar.

(3) Without *very* major changes to Python, you're not going to be
able to import just that class (unless it's the entire content of
the module).  You have to import the whole module into memory
anyway.

 > While i understand it would be harder to make it memory efficient,

I'm not sure what you mean by "memory efficient".  If you mean
multiple copies of the module in memory, that won't happen anyway:
Python knows what it has imported already, and when using the "from
module import anothername as alias" syntax, the second time you import
"from module", it reuses the existing copy in memory even though
"module" isn't known in that namespace.  This "new" syntax would be
treated the same way.

If you mean only importing enough of the module to make YourClass
work, I don't think that will ever happen.  That would require a kind
of global knowledge of the application that is difficult, and maybe
theoretically impossible, in a language as dynamic as Python.

 > but this is python not go,

I have no idea what that is supposed to mean.

 > and also this sort feature could be easily optional,

It's not optional for your successors in your job, though.  They have
to read your code.  We care about readers of code (in general, not
just your successor) more than we care about writers of code.  Why
make things more complicated for them?  There has to be a real win in
expressiveness or power here.  I don't see it yet.

We know what happens when you concentrate on making everything as
terse as possible: Perl.  Python will never be a good imitation of
Perl; there's no real point in trying since we already have Perl if we
want it.

 > also, it might even help against circular import issues

You're just blowing smoke here, aren't you?  I see no reason why this
would help with circular import issues due to the semantics of import
in Python: you get the whole module whether you need it or not.
Without the global application analysis mentioned previously, "new"
can't know that it's OK to omit any of the imports.

 > Yes i know it's sad php has this feature and python does not

As several other posters say, it's not clear this is a feature at all
from Python's point of view.  I don't think it is.  I've never used
PHP so I have no idea what it's good for, but I suppose the same holds
for it as for Perl: Python doesn't try to be PHP, so any feature that
PHP has but Python doesn't needs to be justified on its merits *in
Python*, not in PHP.

 > and again i'm not proud to say this but it's true.

It's a fact.  There's nothing to be ashamed of.  Diversity is good.

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

[Cameron Simpson]

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/

Re: [Python-ideas] Class autoload

[Steven D'Aprano]

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] Class autoload

[Nathaniel Smith]

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

[Steven D'Aprano]

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

[Greg Ewing]

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

[Terry Reedy]

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] Class autoload

[Terry Reedy]

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] Class autoload

[Rob Cliffe via Python-ideas]

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

[Jamesie Pic]

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

[Chris Angelico]

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

[Eric V. Smith]

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/