Re: pip-sync

2023-07-24 Thread Lars Liedtke via Python-list 
This email contains a secure message that can be read by opening the attachment.





Lars Liedtke
Senior Software Developer

[Tel.]
[Fax]   +49 721 98993-
[E-Mail][email protected]


solute gmbh
Zeppelinstraße 15
76185 Karlsruhe
Germany


[Logo Solute]

Marken der solute gmbh | brands of solute gmbh
[Marken]

Triff uns auf der DMEXCO am 20. und 21. September in Köln und sichere dir die 
Chance auf eine brandneue Apple-Watch bei unserer Live-Auslosung!
Vereinbare hier einen Termin mit uns: 
https://outlook.office365.com/owa/calendar/[email protected]/bookings/

[dmexco 
Banner]

Geschäftsführer | Managing Director: Dr. Thilo Gans, Bernd Vermaaten
Webseite | www.solute.de 
Sitz | Registered Office: Karlsruhe
Registergericht | Register Court: Amtsgericht Mannheim
Registernummer | Register No.: HRB 110579
USt-ID | VAT ID: DE234663798



Informationen zum Datenschutz | Information about privacy policy
https://www.solute.de/ger/datenschutz/grundsaetze-der-datenverarbeitung.php

--- Begin Message ---
Did maybe pip-sync create the venv with --system-site-packages (at least 
that's the commandline option for pip)


I only saw behaviour like this so far, when my venv was with 
--system-site-packages and a package was installed by the system.


Cheers

Lars

Am 21.07.23 um 20:08 schrieb Larry Martell via Python-list:

I am trying to set up and maintain a venv with pip-sync. On my bare
metal I have the apparmor python package installed, but it is not
installed in my venv and it's not in my requirements file. When I run
pip-sync I get:

Found existing installation: apparmor 2.13.3
ERROR: Cannot uninstall 'apparmor'. It is a distutils installed
project and thus we cannot accurately determine which files belong to
it which would lead to only a partial uninstall.

Since it's not installed in the venv why does it want to uninstall it?


OpenPGP_signature
Description: OpenPGP digital signature
--- End Message ---
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: pip-sync

2023-07-24 Thread Lars Liedtke via Python-list 

Did maybe pip-sync create the venv with --system-site-packages (at least that's 
the commandline option for pip)

I only saw behaviour like this so far, when my venv was with 
--system-site-packages and a package was installed by the system.

Sorry for the first mess.
Cheers

Lars


Lars Liedtke
Senior Software Developer

[Tel.]
[Fax]   +49 721 98993-
[E-Mail][email protected]


solute gmbh
Zeppelinstraße 15
76185 Karlsruhe
Germany


[Logo Solute]

Marken der solute gmbh | brands of solute gmbh
[Marken]

Triff uns auf der DMEXCO am 20. und 21. September in Köln und sichere dir die 
Chance auf eine brandneue Apple-Watch bei unserer Live-Auslosung!
Vereinbare hier einen Termin mit uns: 
https://outlook.office365.com/owa/calendar/[email protected]/bookings/

[dmexco 
Banner]

Geschäftsführer | Managing Director: Dr. Thilo Gans, Bernd Vermaaten
Webseite | www.solute.de 
Sitz | Registered Office: Karlsruhe
Registergericht | Register Court: Amtsgericht Mannheim
Registernummer | Register No.: HRB 110579
USt-ID | VAT ID: DE234663798



Informationen zum Datenschutz | Information about privacy policy
https://www.solute.de/ger/datenschutz/grundsaetze-der-datenverarbeitung.php


Am 21.07.23 um 20:08 schrieb Larry Martell via Python-list:

I am trying to set up and maintain a venv with pip-sync. On my bare
metal I have the apparmor python package installed, but it is not
installed in my venv and it's not in my requirements file. When I run
pip-sync I get:

Found existing installation: apparmor 2.13.3
ERROR: Cannot uninstall 'apparmor'. It is a distutils installed
project and thus we cannot accurately determine which files belong to
it which would lead to only a partial uninstall.

Since it's not installed in the venv why does it want to uninstall it?

--
https://mail.python.org/mailman/listinfo/python-list

Re: pip-sync

2023-07-24 Thread Larry Martell via Python-list 
On Fri, Jul 21, 2023 at 11:08 AM Larry Martell  wrote:
>
> I am trying to set up and maintain a venv with pip-sync. On my bare
> metal I have the apparmor python package installed, but it is not
> installed in my venv and it's not in my requirements file. When I run
> pip-sync I get:
>
> Found existing installation: apparmor 2.13.3
> ERROR: Cannot uninstall 'apparmor'. It is a distutils installed
> project and thus we cannot accurately determine which files belong to
> it which would lead to only a partial uninstall.
>
> Since it's not installed in the venv why does it want to uninstall it?

Found out what was going on - I had pip-sync installed on the bare
metal and when I ran it from within the venv it was picking that one
up, which then looked at packages outside the venv. After I
uninstalled it from the bare metal it was then working as expected.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Meta Class Maybe?

2023-07-24 Thread Dom Grigonis via Python-list 


> On 23 Jul 2023, at 02:12, Chris Nyland via Python-list 
>  wrote:
> 
> So I am stuck on a problem. I have a class which I want to use to create
> another class without having to go through the boiler plate of subclassing.
> Specifically because the subclass needs to have certain class attributes
> and I would like to control how those are passed to provide defaults and
> such. What I have working right now is

> class Foo():
>@classmethod
>def method_a(cls): print(cls.name)
> 
> Bar = type('Bar', (Foo,), {'name': 'test1’})


Could you write a more expressive example of what you are trying to do and what 
the problem actually is?

The way you wrote the above doesn’t contain any clues why usual subclassing is 
not appropriate.

By attributes you mean value attributes or methods? Why going the usual route 
of subclassing & controlling their behaviour via constructor arguments isn’t 
working?

> This is sort of fine but the user needs to know how to call type and
> include all the base classes etc.


I don’t get what you mean by this either. Very hard to follow everything that 
went after, given I was lost at this point.

Maybe it’s only me... But I if you clarified these, I might be able to help a 
bit.

DG
-- 
https://mail.python.org/mailman/listinfo/python-list

Odd types.get_original_bases() behavior for classes with generic bases but no type arguments

2023-07-24 Thread Chris Bouchard via Python-list 
(Apologies if this has already been discussed. I tried to search and didn't find
anything relevant.)

I was playing around with 3.12.0b4 this evening and noticed an odd (to me, at
least) behavior with types.get_original_bases(). I hesitate to call it a bug
because I think I understand *why* it's behaving this way—I'm just not sure it's
desirable.


>>> T = typing.TypeVar("T")
>>> class FirstBase(typing.Generic[T]):
... pass
...
>>> class SecondBase(typing.Generic[T]):
... pass
...
>>> class First(FirstBase[int]):
... pass
...
>>> class Second(SecondBase[int]):
... pass
...
>>> class Example(First, Second):
... pass
...
>>> types.get_original_bases(Example)
(FirstBase[int],)
>>> Example.__bases__
(First, Second)
>>> types.get_original_bases(First)
(FirstBase[int],)

In other words, types.get_original_bases(Example) is returning the original base
types for First, rather than its own.

I believe this happens because __orig_bases__ is only set when one or more bases
are not types. In this case both bases are types, so Example doesn't get its own
__orig_bases__. Then when types.get_original_bases() tries to get __orig_bases__
with getattr(cls, "__orig_bases__") or something morally equivalent, it searches
the MRO and finds __orig_bases__ on First.

The same thing also happens if all the bases are "bare" generic types.

>>> class First(typing.Generic[T]):
... pass
...
>>> class Second(typing.Generic[T]):
... pass
...
>>> class Example(First, Second):
... pass
...
>>> types.get_original_bases(Example)
(typing.Generic[~T],)

As I said, I'm not clear if this is a bug, or just an unfortunate but intended
behavior. I would personally expect types.get_original_bases() to check if the
type has its *own* __orig_bases__ attribute, and to fall back to __bases__
otherwise. The way it works today makes it unnecessarily difficult to write a
function that, for example, recurses down a type's inheritance tree inspecting
the original bases—I currently have to work around this behavior via hacks like
checking "__orig_bases__" in cls.__dict__ or any(types.get_original_bases(cls)
== types.get_original_bases(base) for base in cls.__bases__). (Unless I'm
missing some simpler solution.)

Is this something that could (should?) be addressed before 3.12 lands?

Thanks,
Chris Bouchard
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Odd types.get_original_bases() behavior for classes with generic bases but no type arguments

2023-07-24 Thread Chris Bouchard via Python-list 
> >>> Example.__bases__
> (First, Second)

Sorry, that should have been

>>> Example.__bases__
(, )

That's what I get for writing an example from memory rather than copying it from
a REPL session. It doesn't change the point I wanted to make, though.

Thanks,
Chris Bouchard
-- 
https://mail.python.org/mailman/listinfo/python-list