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/
