exactly and this issue is for worksheet properties, the other issue and my merge request were for document properties only. I linked to both in the issue description:
worksheet custom properties? Not just document custom properties?
One other thing I'd potentially like to do is modifying wb.copy_worksheet()
and/or WorksheetCopy()
so that you can copy a sheet from one workbook to another (#1901 (closed)). I realize this is not that trivial but I have a need at my company for this and will end up writing some kind of script to do this with/without openpyxl in the short-term but may be worth trying to add to this library if possible. (We are also using some scripts to read/write Worksheet.CustomProperties and Workbook.CustomDocumentProperties without openpyxl as we had an immediate need for that - again I thought it would be nice to add both to this library if possible).
https://peps.python.org/pep-0585/
from __future__ import annotations
def find(haystack: dict[str, list[int]]) -> int:
...
this makes coding with any modern IDE much easier as you get rich auto-complete / IntelliSense and things like that via LSP (language server protocol). It means you can also run type checkers like mypy etc.
basically just be able to copy a sheet from wb1 to wb2
Hey @charlie.clark startup life has been keeping me fairly busy. I think I changed some f-strings when I made the comment above but didn't get around to re-writing any conditional flow with descriptors. I see this is merged into 3.1? Does that mean you are happy with it as is or just merged it for now and would clean it up before 3.1 is released? I may have some time again soon to do some of this stuff. I'd also like to do #1523 if I can.
Ahh this makes a lot of sense based on my experience. I also installed hg-evolve for my python39 installation and the topics extension was not working, but when I installed it for my python27 installation it worked. I had always been using TortoiseHg when committing to openpyxl and I had always used it via CLI (which is what informed me that the hg topic
was not working).
Fair enough. To be honest lots of my design decision were driven by how the COM APIs looks:
https://docs.microsoft.com/en-us/office/vba/api/office.documentproperties.add https://docs.microsoft.com/en-us/visualstudio/vsto/how-to-create-and-modify-custom-document-properties?view=vs-2019 https://docs.microsoft.com/en-us/dotnet/api/microsoft.office.core.documentproperties.add?view=office-pia
That's why I called the classes originally CustomDocumentProperty
and CustomDocumentProperties
and why I implemented an add method. That most closely followed the COM APIs. I probably did that as I use those APIs quite a lot, so slightly biased.
I understand that the openpyxl api is different, but my idea was that if a "defacto standard" already exits, I would just follow it, rather than re-inventing things. I know python favours snake_case rather than camelCase (JavaScript, etc.) or PascalCase (.NET, etc.) but my idea was just stick to the same naming of classes and methods were possible, but translating from PascalCase to snake_case etc.
Obviously, it doesn't make sense for me to implement one feature by closely following the COM APIs, if the rest of openpyxl does not do the same. That could be confusing.
Hey @charlie.clark - I made a couple of comments directly on this commit as I couldn't see a way to comment it as part of either the old or this new MR: 1b8d093649c2
Lines 76 and 135:
str: "lwpstr",
? as the XML string tag is "lwpstr".Alex Ley (092e3d23) at 02 Jun 23:02
fix: typo extra bracket in docs
Hey @charlie.clark,
I did the following and I got your commits/changes merged/pulled into my local working copy of the topic (I believe):
PS ~\Programming\Projects\openpyxl> hg pull
pulling from https://foss.heptapod.net/openpyxl/openpyxl
searching for changes
adding changesets
adding manifests
adding file changes
added 8 changesets with 12 changes to 8 files
new changesets 963db110512c:a53c549b2df4 (3 drafts)
7 local changesets published
(run 'hg update' to get a working copy)
PS ~\Programming\Projects\openpyxl> hg topics
MergedCellProtection (3 changesets)
bitbucket-pr-224 (3 changesets)
bitbucket-pr-345 (2 changesets)
bitbucket-pr-366 (1 changesets)
bitbucket-pr-369 (1 changesets)
bitbucket-pr-371 (2 changesets)
bitbucket-pr-372 (1 changesets)
bitbucket-pr-376 (1 changesets)
bitbucket-pr-380 (1 changesets)
datetime_updates (4 changesets)
fix-datetime-rounding (2 changesets)
fix-doc-link (1 changesets)
fixes-1684 (1 changesets)
issue-1450-file-descriptor-leak (1 changesets)
issue-1530 (2 changesets)
* workbook-customDocProps (3 changesets)
PS ~\Programming\Projects\openpyxl> hg update workbook-customDocProps
merging doc\workbook_custom_doc_props.rst
running merge tool kdiff3 for file doc\workbook_custom_doc_props.rst
7 files updated, 1 files merged, 0 files removed, 0 files unresolved
PS ~\Programming\Projects\openpyxl>
If I make any changes now, should I make them on this local working copy of the topic again and just push to the remote?
EDIT: seems like a push with a change would automatically go to the new MR: openpyxl/openpyxl!407 (merged)
@charlie.clark on line 135, we would set the value to something if the user set it in the constructor. However, if the user also set the linkTarget, we should not allow this? As a CustomProperty can have a value or it can have a linkTarget, I don't believe it can have both? (as the value for the linkTarget is used as the value, so you can't set another independently)
@charlie.clark should this be str: "lwpstr",
? as the XML string tag is "lwpstr".
Ok thanks a lot, this is a great starting point. I will try to incorporate this.
Yeah, I might need to read the Python Cookbook again, then I can try to re-write with descriptors.
Yeah good point, I can add the case when PropVal and LinkTarget are both None as a guard clause at the top. Will do.
What do you mean by no autoconversion exactly?
There are three ways, to call the add function currently:
wb.custom_doc_props.add('TestDocProp2', 1) # I had considered this auto-detection of python int type
wb.custom_doc_props.add('TestDocProp2', "1", int) # explicit conversion
wb.custom_doc_props.add('TestDocProp2', "1", "int") # explicit conversion using type name string
What were you expecting?
done
Alex Ley (f79c99c8) at 01 Jun 22:40
style: use f-strings