Doubts on openpyxl, python3 - python-3.x

He guys, I am just a beginner in Python3. I have a question :
import openpyxl
from openpyxl.style import *
As you can see that I am importing the openpyxl module, but why I need to import the second one in order to style fonts and cells an on.

openpyxl is a package. It contains modules, such as style. You should import the package anyway (all package or individual items). You can either:
import openpyxl
from openpyxl.style import *
then use style items like item1, item2
or
from openpyxl import style
then use style items like style.item1, style.item2

You don't have to - you can just as easily do:
import openpyxl
openpyxl.styles.fonts()
Or:
from openpyxl import style
style.fonts()
It comes down to personal preference. Using * imports is generally frowned upon because there's a risk of polluting the namespace, but if you know this isn't going to happen, and you want to keep your lines of code shorter, it's acceptable.

You are importing openpyxl, which includes everything in openpyxl including openpyxl.style and everything inside that. But say you would like to use X function of openpyxl.style, then you would have to write:
openpyxl.style.X()
If you write the second line you can simpy write:
X()
Basically the second line imports all the contents of the namespace openpyxl.style into your current namespace, removing the hassle of having to write openpyxl.style. everytime. Although it is generally a good practice to not merge namespaces like this, and not use
from _________ import *
Rather you can write
import openpyxl.style as op
and then use the X function as :
op.X()
You can also omit the line
import openpyxl
if you are not using anything else from openpyxl other than that included in openpyxl.style

Related

Spyder reorders my import statements - breaks function

I am using Spyder as Editor/IDE.
I play with the options to include files/function/modules form other olders just to get a better understanding of how it works.
But Spyder rearranges my import statements in alphabetical order and thus breaks my functionality:
This is what I need:
import sys
sys.path.insert(1,'d:/pathtohelloworld/')
import helloworld
But when I do "Save File" in Spyder, it rearranges to
import helloworld
import sys
sys.path.insert(1,'d:/pathtohelloworld/')
and of course it will fail, since it cannot import "helloworld" before the path is defined via sys.path.insert.
This alphabetical order might be a good python style, but how can I fix this issue ?

inspect.py file in folder makes importing pandas not work anymore

I am sorry if this is a silly question but I came across a wierd behaviour. I have a folder with some files, one of them named inspect.py
However, if I change the name inspect.py to somethingelse.py, importing pandas starts working.
I would really like to understand why this is. I assume it has something to do with the module called inspect which (I THINK??) comes by default installed.
Can anyone help me understand this, please?
Looking a np.ma.core.py I see
import builtins
import inspect
import operator
import warnings
import textwrap
import re
These are all base Python modules. Your local inspect.py gets imported instead, which messes with the importing the rest of np.ma.core, and numpy in turn. And pandas depends on numpy.

How Can I Import A Python 3 Module With A Period In The Filename?

What is the proper way to import a script that contains a period, such as program_1.4.py, ideally using importlib?
(Now that the imp module is deprecated, this this answer no longer applies: How to reference python package when filename contains a period .)
After looking through the CPython quite a lot and coming back to some other solutions (especially Import arbitrary python source file. (Python 3.3+)), I realized that I needed to pass the full path to my module. Here is the cross-platform, call-location-independent solution:
"""
import os, sys # For running from Notepad++ shortcut, etc
import importlib.machinery
program_1_4 = importlib.machinery.SourceFileLoader('program_1.4', os.path.join(sys.path[0], 'program_1.4.py')).load_module()
print(program_1_4)
program_1_4.main()
"""

How to set dash style to majorGridlines with openpyxl

Python 3.7, Openpyxl 2.5.12, O.S. Windows 7.
I would like to get majorGridlines with dot style. Is it possible to get this with openpyxl?
I have checked openpyxl.drawing.line.LineProperties class and I have seen there is an option called prstDash = "dot". I have managed to get dash and dot styles with different series of a ScatterChart() like:
serie.graphicalProperties.line.dashStyle = "sysDot"
However, I am not able to give this property to majorGridLines. Is there any way of doing it?
The best thing to do is to create a sample file with the styling you need and compare it with one created or processed by openpyxl. openpyxl implements the OOXML pretty closely so it should be possible to work out how what you need.
Update : 2022
Openpyxl 3.0.10, Python 3.8.3
#required modules to import
import openpyxl
from openpyxl.chart.shapes import GraphicalProperties
from openpyxl.drawing.line import LineProperties
from openpyxl.chart.axis import ChartLines
#Add dash style to majorgridlines or minorgridlines
chart = ScatterChart()
chart.y_axis.majorGridlines=
ChartLines(spPr=GraphicalProperties(ln=LineProperties(prstDash
= 'dash'))))

Mutual imports; difference between import's standart, "from" and "as" syntax

Given this simple folder structure
/main.py
/project/a.py
/project/b.py
main.py is executed by the python interpreter and contains a single line, import project.a.
a and b are modules, they need to import each other. A way to achieve this would be
import project.[a|b]
When working with deeper nested folder structures you don't want to write the entire path everytime you use a module e.g.
import project.foo.bar
project.foo.bar.set_flag(project.foo.bar.SUPER)
Both from project import [a|b] and import project.[a|b] as [a|b] result in an import error (when used in both, a and b).
What is different between the standart import syntax and the from or as syntax? Why is only the standart syntax working for mutual imports?
And more importantly, is there a simple and clean way to import modules that allows mutual imports and assigning shorter names to them (ideally the modules basename e.g. bar in the case of project.foo.bar)?
When you do either import project.a or from project import a, the following happens:
The module object for project.a is placed into sys.modules. This is a dictionary that maps each module name to its module object, so you'll have sys.modules = {..., 'p.a': <module 'p.a' from '.../project/a.py'>, ...}.
The code for the module is executed.
The a attribute is added to project.
Now, here is the difference between import project.a and from project import a:
import project.a just looks for sys.modules['project.a']. If it exists, it binds the name project using sys.modules['project'].
from project import a looks for sys.modules['project'] and then checks if the project module has an a attribute.
You can think of from project import a as an equivalent to the following two lines:
import project.a # not problematic
a = project.a # causes an error
That why you are seeing an exception only when doing from project import a: sys.modules['project.a'] exists, but project does not yet have a a attribute.
The quickest solution would be to simply avoid circular imports. But if you can't, then the usual strategies are:
Import as late as possible. Suppose that your a.py looks like this:
from project import b
def something():
return b.something_else()
Rewrite it as follows:
def something():
from project import b
return b.something_else()
Of course, you would have to repeat imports in all your functions.
Use lazy imports. Lazy imports are not standard feature of Python, but you can find many implementations around. They work by using the "import as late as possible" principle, but they add some syntactic sugar to let you write fewer code.
Cheat, and use sys.modules, like this:
import sys
import project.a
a = sys.modules['project.a']
Very un-pythonic, but works.
Obviously, whatever solution you choose, you won't be able to access the attributes from a or b until the modules have been fully loaded.

Resources