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 -- ∞
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/
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
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.
On 03Mar2018 19:46, Jamesie Pic <jpic@yourlabs.org> 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 <cs@cskk.id.au>
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,
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~
On Sun, Mar 4, 2018 at 4:12 AM, Jamesie Pic <jpic@yourlabs.org> 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
On 4 March 2018 at 03:42, Chris Angelico <rosuav@gmail.com> wrote:
On Sun, Mar 4, 2018 at 4:12 AM, Jamesie Pic <jpic@yourlabs.org> 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 | ncoghlan@gmail.com | Brisbane, Australia
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
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
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
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
On Sat, Mar 3, 2018 at 9:12 AM, Jamesie Pic <jpic@yourlabs.org> 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
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
participants (12)
-
Cameron Simpson -
Chris Angelico -
Eric V. Smith -
Ethan Furman -
Greg Ewing -
Jamesie Pic -
Nathaniel Smith -
Nick Coghlan -
Rob Cliffe -
Stephen J. Turnbull -
Steven D'Aprano -
Terry Reedy