On Thursday, September 22, 2016 at 4:14:16 PM UTC+12, Peng Yu wrote:
>
> ... I want know where import is defined in the source code.
This <https://github.com/python/cpython/blob/master/Python/import.c> looks like
the code, and this
<https://github.com/python/cpython/blob/maste
Hi, I want know where import is defined in the source code. Is it
implemented using __import__?
--
Regards,
Peng
--
https://mail.python.org/mailman/listinfo/python-list
Suppose I have a function which uses a few external libraries,
and this function is only called once every 10 executions.
Does it make sense to import these libraries for the whole module?
import sys
def fun():
import x, y, z
Something like this is acceptable/good practice in the scenario
On Thu, Feb 17, 2011 at 8:44 AM, andrea crotti
andrea.crott...@gmail.com wrote:
Suppose I have a function which uses a few external libraries,
and this function is only called once every 10 executions.
Does it make sense to import these libraries for the whole module?
Yes. Having all the
2011/2/17 Chris Rebert c...@rebertia.com
Yes, of course. Importing a module multiple times (as would happen if
fun() is called multiple times) is obviously slower than just
importing it once, although the 2nd and subsequent imports will be
faster as Python will just return another reference
On 2/17/2011 12:27 PM, andrea crotti wrote:
Well no I wasn't really worried about performances.
I just thought that if an external module is really almost never used,
it might make sense to import it only when it's really needed.
If the module is only used in one function and the function may
As a general rule, I group all my imports in the beginning of the module's
source, even if it is only used a handful of times by a few functions.
However, on such cases as the import is only needed by specific function(s)
zero or once, then I do the import in the function itself. Importing
Hi!
If I have two files .py such as
m.py
from c import *
...
x=c()
...
os.any_method ...
...
c.py
class c:
def __init__(self, ...):
...
os.any_method ...
Paulo da Silva [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| Hi!
|
| If I have two files .py such as
|
| m.py
| from c import *
| ...
| x=c()
| ...
| os.any_method ...
| ...
|
| c.py
| class c:
| def __init__(self, ...):
| ...
| os.any_method ...
| ...
| ...
|
| both using os
Paulo da Silva a écrit :
Hi!
If I have two files .py such as
m.py
from c import *
avoid this kind of import except in an interactive interpreter and
eventually in a package __init__.py. Better to use either:
from c import c
or
import c
...
x = c.c()
...
both using os module where should I put the import os? In both files?
You don't really have a choice, you have to import os in both files.
Python will only load the os module into memory once, but the import
statements are needed to add the os module to the c and m module
namespaces. The code in
Paulo da Silva [EMAIL PROTECTED] writes:
Hi!
If I have two files .py such as
m.py
from c import *
Best done as either
import c# then use 'x = c.c()'
or
from c import c
Using 'from foo import *' leads to names appearing in your current
namespace that are difficult to
Paulo da Silva escreveu:
This is to thank all the answers I got so far.
Now I understand perfectly how import works.
Regards.
Paulo
--
http://mail.python.org/mailman/listinfo/python-list
Paulo da Silva escreveu:
This is to thank all the answers I got so far.
Now I understand perfectly how import works.
Regards.
Paulo
--
http://mail.python.org/mailman/listinfo/python-list
Bruno Desthuilliers escreveu:
Paulo da Silva a écrit :
...
c.py
class c:
class C(object):
1/ better to stick to naming conventions (class names in CamelCase)
Ok. Thanks.
2/ do yourself a favor: use new-style classes
I still have python 2.4.3 (The gentoo current version).
I
Paulo da Silva a écrit :
Bruno Desthuilliers escreveu:
Paulo da Silva a écrit :
...
c.py
class c:
class C(object):
1/ better to stick to naming conventions (class names in CamelCase)
Ok. Thanks.
FWIW:
http://www.python.org/dev/peps/pep-0008/
2/ do yourself a favor: use
On Mar 8, 5:49 pm, Bruno Desthuilliers
[EMAIL PROTECTED]
1/ better to stick to naming conventions (class names in CamelCase)
Ok. Thanks.
FWIW:http://www.python.org/dev/peps/pep-0008/
By my reading, PEP8 doesn't specify CamelCase as preferred over the
other styles it mentions. non_camel_case
Disregard my last message, I'm stupid. I totally missed that Bruno was
talking about classname. Bruno is exactly right.
--
http://mail.python.org/mailman/listinfo/python-list
En Fri, 09 Mar 2007 01:09:36 -0300, MonkeeSage [EMAIL PROTECTED]
escribió:
FWIW:http://www.python.org/dev/peps/pep-0008/
By my reading, PEP8 doesn't specify CamelCase as preferred over the
other styles it mentions. non_camel_case is also considered good
style, as I understand (and is used
On Mar 8, 10:27 pm, Gabriel Genellina [EMAIL PROTECTED]
wrote:
Class names should be CamelCase. Read it again, and notice the difference
between a Descriptive section and a Prescriptive one.
Yes, I misread Bruno's comment (missed that he was speaking of class
names). Disregard my post.
--
Gabriel Genellina [EMAIL PROTECTED] writes:
Class names should be CamelCase.
Note that the term camel case has ambiguous usage. Some use it to
refer to *both* of nameWithSeveralWords and NameWithSeveralWords.
I prefer to use the term title case to refer unambiguously to
NameWithSeveralWords,
21 matches
Mail list logo
