Ok there's something wrong with the CI itself

what would be needed in order to do it from this repository (on a separate branch?)

this is against the common practices ... this way you would get a .deb file not a Debian package.

Debian is still obsessed about .tar.gz and these would then be loaded on https://salsa.debian.org/
(to create another .tar.gz for the build servers :-) )

what would be needed in order to do it from this repository (on a separate branch?)

this is against the common practices ... this way you would get a .deb file not a Debian package.

Debian is still obsessed about .tar.gz and these would then be loaded on https://salsa.debian.org/ (to create another .tar.gz for the build servers :-) )

OK, we can do whatever is best practice. The only thing that would be important to me is that we find a way that could be "recoverable" if you would stop packaging python-escpos. I have tried (with the organization) to have the python-escpos package at least somehow hosted in a such a way that somebody else could step up and take this over with (hopefully) not too much trouble, should I stop doing this some day. (Ideally, there would be a transition, but you never know)

I'm aware of this too strong ownership of packages in the Debian project.

I got shouted at by some survivalist living of the grid 11 months in a row
and going online once a year. "It's my package"

I will package it under the "Python team" with a disclaimer that anyone else can update it.

I'm aware of this too strong ownership of packages in the Debian project.

I got shouted at by some survivalist living of the grid 11 months in a row and going online once a year. "It's my package"

I will package it under the "Python team" with a disclaimer that anyone else can update it.

That would be great :-)

I have created a PR that refactors everything to f-strings: #608. If you do not mind merging or rebasing your branch, I would merge that into master.

If you do not mind merging

I do not use an ide ... still nano ... :-|

If you do not mind merging

I do not use an ide ... still nano ... :-|

I have checked and it is rather easy to merge. If that is OK for you, I would merge #608 and merge the changes into your branch, then you just have to pull :-)

Yes please.

Yes please.

Done

Now there is only one thing left in the CI:

  py38: commands[0]> pytest
  ImportError while loading conftest '/home/runner/work/python-escpos/python-escpos/test/conftest.py'.
  test/conftest.py:4: in <module>
      from escpos.printer import LP, CupsPrinter, Dummy, File, Network, Serial, Usb, Win32Raw
  .tox/py38/lib/python3.8/site-packages/escpos/printer/__init__.py:4: in <module>
      from .cups import CupsPrinter
  .tox/py38/lib/python3.8/site-packages/escpos/printer/cups.py:16: in <module>
      from ..escpos import Escpos
  .tox/py38/lib/python3.8/site-packages/escpos/escpos.py:1363: in <module>
      class EscposIO:
  .tox/py38/lib/python3.8/site-packages/escpos/escpos.py:1441: in EscposIO
      self, type: type[BaseException], value: BaseException, traceback: TracebackType
  E   TypeError: 'type' object is not subscriptable

I will soon be offline for today and cannot approve the CI runs. But you can also execute the tests locally with e.g. tox -e py310 if you want to try out changes.

I think the issue was that one: 369e709, feel free to revert if that is not what you meant.

I would have proposed a from __future__ import annotations

Your solution is the perfect one for python3.8, which I'm not used to work with (I do 2.6, 2.7, 3.7, 3.11, 3.12)

Your solution is the perfect one for python3.8, which I'm not used to work with (I do 2.6, 2.7, 3.7, 3.11, 3.12)

OK, but then I would prefer that we git revert 369e709, because I would prefer more the way how it will be done in the future.

Your solution is the perfect one for python3.8, which I'm not used to work with (I do 2.6, 2.7, 3.7, 3.11, 3.12)

OK, but then I would prefer that we git revert 369e709, because I would prefer more the way how it will be done in the future.

I have cleaned up my commit

I would prefer more the way how it will be done in the future.

pyupgrade can do it automaticaly for you when you bump your baseline.

Optional[a] becomes a | None
Union[a|b] becomes a | b

most uppercase imports from typing are replaced by lowercase ones from standard library
List -> list

but it's easier to keep it 3.8 coherent for now.

src/escpos/escpos.py:1278: error: Incompatible return value type (got "bytes", expected "list[int]") [return-value]

this looks like a real bug

src/escpos/escpos.py:1278: error: Incompatible return value type (got "bytes", expected "list[int]") [return-value]

this looks like a real bug

Is this about the return value of the cups driver? If yes, maybe @belono can help? It looks like the return value of _read is not compatible with the rest of the lib for this driver.

There's Escpos && EscposIO:

One close() is missing

class Escpos

    def __del__(self):
        """Call self.close upon deletion."""
        self.close()


class EscposIO:
    r"""ESC/POS Printer IO object.
       def __init__(
        self, printer: Escpos, autocut: bool = True, autoclose: bool = True, **kwargs
    ) -> None:
        """Initialize object.
        :param printer: An EscPos-printer object
        """
        self.printer = printer

 def close(self) -> None:
        """Close printer.

        Called upon closing the `with`-statement.
        """
        self.printer.close()

It's a baseclass, so maybe just addig "def close(): pass" is enough

I know nothing about win32, but the typing in the stubs feels wrong.

/usr/lib/python3/dist-packages/win32-stubs/win32print.pyi:def WritePrinter(hprinter: _win32typing.PyPrinterHANDLE, buf: str): ...

BTW the ) -> None: has one specific purpose: it tells mypy that annotation job has been done and it can proceed with further checking. This makes more hints show up.

Codecov Report

Merging #607 (b634354) into master (06bdb56) will decrease coverage by 0.22%.
The diff coverage is 90.32%.

@@            Coverage Diff             @@
##           master     #607      +/-   ##
==========================================
- Coverage   80.98%   80.77%   -0.22%     
==========================================
  Files          21       21              
  Lines        1620     1633      +13     
  Branches      288      286       -2     
==========================================
+ Hits         1312     1319       +7     
- Misses        226      233       +7     
+ Partials       82       81       -1     

Flags with carried forward coverage won't be shown. Click here to find out more.

Hi @a-detiste, are you ready with the change? (CI is passing)If yes, I would try to fit in a final review, but otherwise we can also wait of course.
Would it be possible to change the mypy ci step to be more strict? (Or do we have remaining issues there?)

Hi, I would like to slow down before my Holydays (from 20), so let's wrap this up.

mypy --strict generates 400 errors, it's way too early.

Ok, well this would be quite a lot still, haven't checked mypy directly.

Should we merge this pr now? Then you can open a new one for the next steps when you get to it

Yes please merge.

I will track on my side the dependecies that needs:

• annotations
• packaging in Debian

I need to package python3-barcode first

please include examples/ in mypy run.
this helped me understanding & fixing this previous typing error

-tox.ini:commands = mypy src test
+tox.ini:commands = mypy src test examples

-    def __init__(
-        idVendor: str = "",
-        idProduct: str = "",
-        usb_args: Dict[str, str] = {},
    
+    def __init__(
+        self,
+        idVendor: Optional[int] = None,
+     idProduct: Optional[int] = None,
+     usb_args: Dict[str, Union[str, int]] = {},

I left a comment in the cups.py and another one in test_printer_cups.py some days ago. 😄

Please, fix that before merge.

I left a comment in the cups.py and another one in test_printer_cups.py some days ago. 😄

Please, fix that before merge.

Are you sure that you have sent the review? Could it be still pending? I cannot see those comments unfortunately. 😕