PyPDF2 cleanup #684
Replies: 9 comments
-
|
Assuming ownership of PyPDF2, why not just make any and all breaking changes as part of this repository, bumping the major version? For some stuff like the If the intention is that no one should use |
Beta Was this translation helpful? Give feedback.
-
Good point! I'm hesitant with making breaking changes to a widely used library, but if it's properly communicated I guess it's OK 🤔
Yes, I like that a lot! Scipy / flask do this pretty well
The problem I have with PyPDF is that it was not maintained for such a long time. I have recommended multiple times not to use it because of that. On the other hand, a change to a new package only improves the situation of most of the community moves and if that project keeps getting progress. If we would get the "pdf" package on pypi, that could work. I've just started fiddling around with a new package that should define a clean and modern interface to interact with pdf : https://pypi.org/project/pdffile |
Beta Was this translation helpful? Give feedback.
-
|
What in particular in 3.7+ is required in your opinion to drop 3.6 support for a new major version? |
Beta Was this translation helpful? Give feedback.
-
|
Python 3.6 is deprecated since 23.12.2021: https://peps.python.org/pep-0494/ While I would not break compatibility on purpose, this means to me that we can use new features. While I'm not sure if it's necessary for PyPDF2, posponed annotation evaluation is a feature I typically miss in Python 3.6 (link) |
Beta Was this translation helpful? Give feedback.
-
|
I'm sure as a full blown programmer, you like what you refer to as magic methods, but I like knowing what is being called. If I couldn't have understood what process was being accessed (such as getPage or get_page in your example) I would have had no idea what the code was doing. |
Beta Was this translation helpful? Give feedback.
-
|
A search for PDF and Python shows an amazing number of projects that use PyPDF2 and therefore the existing interface. I think that we could go a long way without changing the interface by applying the latest standards to the internals. |
Beta Was this translation helpful? Give feedback.
-
I feel like the right course might be that once work for a 2.0 release happens, we try for 3.6 compatibility (as indicated in #659, a number of people still use it), in that if it turns out that some feature from 3.7 would make our lives drastically better, so be it, 3.6 is dropped. I'd just like to avoid dropping 3.6 support (as it is still somewhat widely used yet) just for the sake of dropping support. I do agree on dropping anything before 3.6 for both f-strings and annotations though. 👍
This could be rolled out without breaking BC and also not duplicating function names by doing something like: class Foo:
def getPage(self, num):
print(num)
def _get_attribute_error(self, name):
return AttributeError(f"'{self.__class__.__name__}' object has no attribute '{name}'")
def _get_func(self, name):
words = name.split('_')
new_name = words[0] + ''.join(word.title() for word in words[1:])
try:
return getattr(self, new_name)
except AttributeError as exc:
pass
raise self._get_attribute_error(name)
def __getattr__(self, name):
if '_' not in name:
raise self._get_attribute_error(name)
return self._get_func(name)
a = Foo()
a.getPage(1)
a.get_page(2)
a.invalid_func(3)Then in 2.0, we reverse some logic here (so that we have |
Beta Was this translation helpful? Give feedback.
-
|
Sounds awesome @MasterOdin ! Let's do it like that! By the way: I've just released 1.27.0 with several tiny changes and a few bugfixes 🎉 |
Beta Was this translation helpful? Give feedback.
-
|
If we want to support it, we need to test it: #667 - Python 3.6 is now in the CI |
Beta Was this translation helpful? Give feedback.
-
I'd be interested in (organizing/doing) a cleanup for Python 3.7+.
The breaking changes I'd like to see:
getPageshould beget_pagepdf_reader.get_page(0)I'd rather usepdf_reader[0]- that needs a lot of discussion!Step 1: Code changes
Copy the current code in a new repositoryNew package name
It would be pretty amazing if we could get
pdfon PyPI. I've just contacted the current author; let's see 😇Then the new package could simply be called pdf and PyPDF2 would be the adapter package using pdf
Step 2: Use PyPDF2 as an adapter
Make PyPDF2 use the new package (dropping <= Python 3.6 support!)
In order to make sure that people move to the new project, there could be a drop-in adapter package for People who are on Python 3.7+. That package could then use the new package under the hood, but provide the old interface to its users (additionally to the new one, maybe with deprecation warnings?).
If possible, that adapter package would be PyPDF2 itself.
Step 3: Spread the word
To make sure people actually use the new PDF package
Beta Was this translation helpful? Give feedback.
All reactions