#pyqt | Logs for 2020-06-14

Back
[01:12:34] -!- alexhugo has quit [Ping timeout: 240 seconds]
[02:09:05] -!- alexhugo has joined #pyqt
[02:22:37] -!- sazawal has joined #pyqt
[02:45:56] -!- jmarsac has joined #pyqt
[03:08:23] -!- cottoneyejim has joined #pyqt
[03:37:41] -!- cottoneyejim has quit [Quit: cottoneyejim]
[03:38:31] -!- jmarsac has quit [Ping timeout: 272 seconds]
[03:53:22] -!- alexhugo has quit [Ping timeout: 260 seconds]
[04:07:24] -!- Belxjander has joined #pyqt
[04:13:49] -!- SpinTronix has joined #pyqt
[04:49:13] -!- alexhugo has joined #pyqt
[05:07:26] -!- BPL has joined #pyqt
[06:33:10] -!- alexhugo has quit [Ping timeout: 246 seconds]
[06:52:43] -!- jmarsac has joined #pyqt
[07:29:22] -!- alexhugo has joined #pyqt
[08:27:19] -!- jmarsac has quit [Ping timeout: 272 seconds]
[09:13:26] -!- alexhugo has quit [Ping timeout: 265 seconds]
[09:16:32] -!- yustin has joined #pyqt
[09:30:06] -!- yustin has quit [Ping timeout: 258 seconds]
[10:09:29] -!- alexhugo has joined #pyqt
[10:40:33] <ali1234> what is the best way to make my menus?
[10:41:46] <Avaris> qmenu?
[10:42:00] <ali1234> you can't simply use qmenu
[10:42:13] <Avaris> i can't?
[10:42:26] <ali1234> it isn't very pythonic
[10:42:42] <ali1234> it takes a huge amount of code to make even one simple menu item
[10:43:21] <Avaris> are we talking about the same thing? qmenu.addAction(....)
[10:43:37] <ali1234> lol
[10:43:39] <ali1234> yes
[10:45:02] <Avaris> so... what is this huge amount of code you were talking about?
[10:45:28] <ali1234> a = QtWidgets.QAction('name', window)
[10:45:35] <ali1234> a.setShortcut('whatever')
[10:45:44] <ali1234> a.triggered.connect(callable)
[10:45:53] <ali1234> menu.addAction(a)
[10:45:53] <altendky> ali1234: qt isn't super pythonic. given that it is c++ this is perfectly reasonable
[10:46:05] <ali1234> for every single menu item you have
[10:46:34] <altendky> ali1234: and pyqt5 is a thin layer around qt. so it's reasonable it doesn't change this. but sure, i am curious what a python library backed by qt would look like and how well it would work out to be based on qt but not match it's api
[10:46:37] <ali1234> that's assuming they are just regular type. if you want a radio group or a toggle it is even worse
[10:46:51] <altendky> ali1234: you can write a function
[10:46:56] <ali1234> yeah i have :)
[10:46:57] <Avaris> 1. don't construct an action if you don't intend to use it elsewhere, simply use addAction of qmenu
[10:47:03] <ali1234> i figured somebody might have already written one
[10:47:26] <altendky> ali1234: i am not familiar with a good helper library for pyqt. though i haven't looked a lot.
[10:47:52] <ali1234> https://bpa.st
[10:48:08] <ali1234> unfortunately it does not support radio and toggle, which i now need
[10:48:21] <Avaris> 2. https://doc.bccnsoft.com
[10:48:29] <ali1234> i also need to be able to change properties in code and have the toggle menu items update to reflect that, so i do need to use them elsewhere
[10:48:30] <altendky> here's an example menu i've got. context menu, but still. https://github.com
[10:48:37] <altendky> Avaris: uh... bccnsoft? :]
[10:48:39] <Avaris> err what's that doc domain
[10:49:16] <Avaris> that comes as first in search ... :|
[10:49:24] <ali1234> i;ve been on that domain a lot the past week
[10:49:25] <altendky> yup.
[10:49:28] <altendky> :[
[10:49:45] <altendky> ali1234: use official pyqt for pyqt stuff and official qt for qt stuff
[10:49:55] <ali1234> what is official pyqt?
[10:49:58] <Avaris> https://www.riverbankcomputing.com
[10:50:17] <Avaris> i had to go through loops to find that one
[10:50:20] <ali1234> and what is bccnsoft?
[10:50:29] <altendky> some personal page it looks like where they have some docs they like
[10:50:48] <Avaris> i have no idea what bccnsoft is, but appears to be mirror... i guess
[10:51:07] <altendky> they also have php and various other docs if you go to the root
[10:51:33] <ali1234> i dont get why you linked to that qt properties doc...
[10:52:11] <ali1234> when i say properties i mean python properties
[10:52:13] <Avaris> example in that page does your 4 line code in a single constructor
[10:52:36] <altendky> ali1234: perhaps you want pyqt properties because they are python properties but also qt properties. which give you signals and slots
[10:52:46] <altendky> err, signals? anyways
[10:53:03] <altendky> you want your stuff integrated with qt stuff so qt stuff might do that well
[10:53:10] <ali1234> except creating pyqtProperties is almost as painful as creating QMenus :(
[10:53:21] <altendky> ali1234: it's the same painful as creating qt properties?
[10:53:27] <altendky> err, python properties
[10:53:27] <ali1234> yes
[10:53:29] <ali1234> no
[10:53:34] <altendky> ali1234: ok, show the difference...
[10:53:37] <ali1234> we went there the other day :)
[10:53:44] <Avaris> what python property is there? your qaction example above uses only qt properties
[10:53:47] <altendky> ali1234: generating automatically...
[10:54:04] <ali1234> no, my qaction example uses setattr
[10:54:11] <altendky> ali1234: anyways, we had a few paths forward on that i thought. and i thing though not exactly what you wanted does work
[10:54:14] <ali1234> the one on bpaste i mean
[10:54:23] * Avaris looks around for setattr
[10:54:28] <altendky> *and my thing, though not...
[10:54:38] <Avaris> oh i missed that link
[10:55:15] <ali1234> anyway, the difference between python properties and qt properties is for qt properties you have to declare the signal separately, and then explicitly emit it, or nothing works properly
[10:55:27] <altendky> huh?
[10:55:34] <altendky> their point is to have that feature i thought
[10:55:40] <ali1234> what doyou mean huh? we went through all of this the other day
[10:56:04] <altendky> ali1234: we went through difficulty of taking an attrs class and automatically generating a class with pyqtproperties.
[10:56:07] <ali1234> i wanted to have the signal automatically declared and emitted but it isn't possible because it has to exist before the QObject metaclass runs
[10:56:10] <Avaris> yeah, pyqt needs to emit signal explicitly
[10:56:13] <altendky> and i made some suggestions which perhaps you ignored
[10:56:41] <ali1234> i mean it isn't possible without 300 lines of extremely difficult to understand code that hacks object internals
[10:57:06] <altendky> ali1234: i mean like that's unrelated to a pyqtproperty having a signal
[10:58:33] <Avaris> so what's painful about this code in the paste?
[10:58:34] <ali1234> you are right though, i do want to replace my properties with qt properties if i want to reflect the state in the toggle item
[10:59:01] <ali1234> Avaris: it doesn't support toggle items or radio groups, and adding it will mean extending the input data
[10:59:02] <altendky> ali1234: so, did you actually consider any of my suggestions the other day?
[10:59:13] <ali1234> altendky: no, because i couldn't understand them
[11:00:02] <Avaris> ali1234: sure... you make a menu builder scheme thingy. if you want to make it generic, you need to extend it. i'm not sure what you're expecting from qt :)
[11:00:10] <altendky> ali1234: ah... three-arg type lets you dynamically define class attributes instead of typing them in a class def. so you can take an existing class, grab the things in it, shove them or other things (pyqtproperties) into the new class and specify the inheriting class including getting it's metaclass.
[11:00:31] <altendky> as i recall i didn't like this option and my alternative was fine for me but the three-arg type call would have worked. i think
[11:00:32] <ali1234> altendky: that is way too abstract for me to understand
[11:00:42] <altendky> ali1234: sure, because you aren't even trying
[11:00:47] <altendky> ali1234: have you even looked at the docs?
[11:00:52] <ali1234> yes
[11:01:05] <altendky> ali1234: did you run some code and make a class?
[11:01:11] <ali1234> no
[11:01:19] <altendky> ali1234: well... maybe do that small step
[11:02:27] <altendky> anyways, this is one of my big experiences that leads to 'no, just no. just say no to metaclasses'. sure, they can 'do a thing'. but they keep anyone else from 'doing a thing' too.
[11:02:42] -!- yustin has joined #pyqt
[11:03:42] <ali1234> wait which docs are you refering to?
[11:03:52] <altendky> ali1234: three-arg type
[11:04:43] <ali1234> as in calling the built-in python function type() with three arguments?
[11:04:54] <altendky> ali1234: yes
[11:05:03] <Avaris> also, regarding building menus... based on my experience, there is really almost zero benefit to make a generalized building. you generally have a handful menus in an application and it is almost always easier to hand build them
[11:05:22] <ali1234> Avaris: yes it does seem that way
[11:06:10] <altendky> i'm trying an example. it's been a few years
[11:06:14] <ali1234> okay so three arg type makes a new type that didn't exist previously
[11:06:23] <altendky> yup
[11:06:37] <altendky> and let's you dynamically specify class attributes
[11:06:43] <ali1234> how?
[11:06:47] <ali1234> in dict?
[11:06:51] <altendky> by... calling the function per the docs?
[11:07:08] <Avaris> ugh... i'd rather deal with metaclasses than using `type`
[11:07:11] <ali1234> okay
[11:07:29] <ali1234> i don't see how this helps though. i want to declare the properties in the class definition
[11:07:38] <altendky> ali1234: do you know how attrs works?
[11:07:42] <ali1234> no
[11:08:05] <altendky> ali1234: it finds _CountingAttr class attributes and removes them and creates code based on them.
[11:08:23] <altendky> ali1234: so you can theoretically do something similar except you just create a new class based on them.
[11:09:11] <ali1234> so ... instead of declaring the properties, you declare a thing that says "put a property here", then you pass the class to the huge complex machine that replaces them with the actual properties?
[11:09:29] <altendky> ali1234: yup. that's how attrs works. you like attrs, right?
[11:09:41] <altendky> (except for the property part, but they have a ticket about that)
[11:09:43] <ali1234> i like what it does, but looking at how it does it horrifies me
[11:10:01] <altendky> ali1234: ok, then walk away and hand code everything i guess.
[11:10:32] <ali1234> i don't really see why it is necessary to do it that way either
[11:10:39] <ali1234> i mean what is wrong with just using descriptors?
[11:10:56] <ali1234> other than it doesn't work with Qt
[11:11:40] <altendky> ali1234: huh?
[11:11:48] <altendky> why didn't attrs use descriptors?
[11:12:02] <ali1234> yes, why didn't attrs use descriptors?
[11:12:49] <ali1234> i have seen other libraries that do the same thing and do use descriptors
[11:12:57] <altendky> ali1234: i'm sure there's a real discussion of that somewhere but the first point would be that that doesn't leave you with a very normal class and it also doesn't give you any of the stuff attrs does (an __init__, __repr__, etc)
[11:16:21] <ali1234> can you elaborate on "normal class"?
[11:17:27] <altendky> ali1234: the one you would have learned to write from the beginning of writing python. an __init__ that takes args and assigns to attributes etc. attrs does a bunch of stuff. at the end, it's a class without any special stuff really. just generated methods
[11:17:45] <ali1234> what is the benefit of that?
[11:18:05] <Avaris> reduce boilerplate code?
[11:18:13] <altendky> ali1234: why do you like attrs?
[11:18:32] <ali1234> using descriptors removes boilerplate too
[11:18:33] * Avaris doesn't use attrs, for the record :)
[11:18:34] <altendky> i mean this is a perfect case in point for 'why does doing magical stuff (metaclass in this case) make a mess'
[11:18:54] <altendky> and this magic makes us to a pile more magic to amend it
[11:18:58] <altendky> *do a pile
[11:19:10] <altendky> rather than just tossing on a decorator that swaps in a few things
[11:20:18] <ali1234> when i say descriptors i mean the sort where inside your class you say x = MyAttr(type, defaultvalue) and MyAttr is a class that has __get__ and __set__
[11:20:29] <altendky> Avaris: i'll try something else here but why doesn't notify seem to work? https://repl.it
[11:20:37] <altendky> ali1234: yes, that's a descriptor
[11:20:44] <altendky> ali1234: that doesn't get you any of the stuff attrs does
[11:20:47] <ali1234> it seems to me that this is exactly the same as what attrs does
[11:20:53] <ali1234> at least the part of it that i like
[11:21:04] <altendky> ali1234: attrs exactly does _not_ get in the middle of attribute access at all
[11:21:12] <altendky> it creates an __init__
[11:21:17] <altendky> and a __repr__
[11:21:18] <altendky> etc
[11:21:29] <ali1234> it achieves the same result which is me not having to write __init__ and getters/setters
[11:21:35] <Avaris> ali1234: yeah, setter needs to emit signal explicitly. i think qt has some shortcut to auto-emit but doesn't seem to carry on to python
[11:21:45] <Avaris> err altendky ^
[11:21:45] <altendky> ali1234: no, that's not descriptors doing that. that's the metaclass doing that. or at least the parent class
[11:21:55] <ali1234> what metaclass?
[11:21:59] <altendky> Avaris: fun. whatever, this wouldall be generated anyways
[11:22:06] <altendky> ali1234: QObject has a metaclass. that's what makes this mess
[11:22:12] <altendky> ali1234: same for Django
[11:22:16] <ali1234> yes but i am not talking about QObject now, i am talking about attrs
[11:22:17] <altendky> sqla orm i assume
[11:22:29] <altendky> ali1234: yes. attrs doesn't use a metaclass. that's the nice thing
[11:22:31] <altendky> a nice thing
[11:22:34] <ali1234> like i said (16:10:56) ali1234: other than it doesn't work with Qt
[11:22:45] <altendky> ali1234: what about attrs doesn't work with qt? i use it with qt
[11:22:55] <ali1234> i never said it didn't
[11:23:05] <ali1234> immediately before that i said (16:10:39) ali1234: i mean what is wrong with just using descriptors?
[11:23:10] <altendky> 11:22 <ali1234> like i said (16:10:56) ali1234: other than it doesn't work with Qt
[11:23:15] <altendky> what is 'it' there?
[11:23:21] <ali1234> descriptors
[11:23:27] <Avaris> altendky: specifically, qt says it will auto-emit if you omit a setter, but you need to emit yourself if you define a setter. on python side without setter, it is read-only. so...
[11:23:28] <altendky> what about descriptors don't work with qt?
[11:23:40] <ali1234> you can't make one that creates a signal because of the metaclass
[11:23:56] <altendky> ali1234: that's specifically a signal issue afaik
[11:24:00] <ali1234> yes, exactly
[11:24:15] <altendky> ali1234: then stop saying descriptors don't work with qt and attrs should use descriptors
[11:24:17] <ali1234> so if i am not using Qt, why should i use attrs instead of descriptors?
[11:24:18] <altendky> i'm utterly lost
[11:24:29] <altendky> even though i'm writing a solution for you amidst all this
[11:24:39] <altendky> ali1234: descriptors literally do nothing to help implement attrs
[11:24:53] <altendky> ali1234: django etc use a metaclass (which might happen to use descriptors but...)
[11:25:14] <altendky> attrs let's you get declarative definition without a metaclass
[11:25:19] <altendky> or descriptors
[11:25:32] <altendky> i think i need to pull up my attrs vs. regular class example
[11:25:32] <ali1234> and what is the benefit of avoiding descriptors?
[11:25:43] <altendky> ali1234: less complex stuff to deal with
[11:25:53] <altendky> ali1234: i mean do you usually use a descriptor when hand writing a class?
[11:26:02] <ali1234> yes, often
[11:26:11] <altendky> ali1234: it's usually not needed...
[11:26:25] <Avaris> when you say descriptor, do you mean a separate class or does that include @property?
[11:26:34] <ali1234> i mean a separate class
[11:27:21] <altendky> ali1234: the point is. a metaclass is making our lives hell right now. if they had used a more 'regular' means (presumably it wouldn't be quite as 'nifty', but hey) then we wouldn't have to reach for such extreme tools to get where we want
[11:27:33] <ali1234> yes i understand that
[11:27:37] <ali1234> but then you started talking about attrs
[11:27:40] <altendky> ali1234: likewise with descriptors
[11:28:10] <altendky> ali1234: yes, because we are trying to do a similar sort of thing. take a declarative definition and generate a thing from it.
[11:28:56] <altendky> ali1234: https://repl.it here's my example of an attrs class and a (partially) matching hand-written class. attrs generates a pile of methods for you. and you are let with the same thing as if you had written them out by hand yourself.
[11:29:05] <altendky> the magic is contained in the processing. the output doesn't contain magic
[11:29:17] <ali1234> so class A
[11:29:29] <altendky> ali1234: you can't possibly have read that through yet.
[11:29:40] <ali1234> why?
[11:29:54] <altendky> because there's more code than you could have read in a minute
[11:30:09] <ali1234> it's only like 60 lines
[11:30:11] <altendky> ali1234: slow down and think about it a little
[11:30:51] <ali1234> you have class C defining a bunch of properties manually, and class A doing the same thing with attrs
[11:30:52] <altendky> oh hey, i just realized that repl.it is finally actually letting me run pyqt code. yay!
[11:31:19] <ali1234> then you do a bunch of tests proving that they are equivalent
[11:31:38] <altendky> ali1234: next you can look at https://repl.it
[11:32:22] <altendky> that gets us creating a class inheriting from QObject with working properties and signals. so now we're down to 1) generating those functions based on an existing class and 2) copying over the other pieces of the existing class
[11:33:08] <altendky> but probably what Avaris pointed out is part of why i just walked away. if the signal is just some separate thing then whatever, i can make it entirely separate and toss it on a class that holds just signals etc. and then i don't have to dynamically create a class
[11:33:41] <altendky> the code that relates c.a with c.a_notify could as well relate c.a with c.signals.a_notify.
[11:34:13] <altendky> then the original class can stay intact and we just create a signal holder class separately
[11:34:24] <altendky> and we're back to something around what i'm using
[11:35:50] <Avaris> altendky: you still need to give `notify` kwarg to pyqtProperty
[11:35:57] <ali1234> okay so that second paste is much more interesting
[11:36:23] <Avaris> i think QML side uses that
[11:36:27] <ali1234> yes
[11:36:38] <altendky> ah
[11:36:53] <altendky> ali1234: and pointless for the reasons i mentioned
[11:37:12] <altendky> though maybe less pointless regarding the qml stuff
[11:37:16] <ali1234> the signal has to exist when you call pyqtProperty
[11:37:26] <altendky> it does, handily
[11:37:49] <altendky> https://repl.it there's with notify=
[11:37:58] <ali1234> but this still doesn't work?
[11:38:04] <altendky> ali1234: what doesn't work?
[11:38:10] <ali1234> that paste?
[11:38:16] <altendky> ali1234: what about it doesn't work?
[11:38:23] <ali1234> i don't know. why is it pointless if it works?
[11:38:42] <altendky> ali1234: all the stuf fi wrote at :32-:34
[11:39:32] <ali1234> print('about to change')?
[11:39:47] <altendky> ali1234: what about that is confusing
[11:40:08] <ali1234> why is it pointless?
[11:40:20] <altendky> ali1234: why is the print you shared pointless?
[11:40:31] <ali1234> why does it make the whole of the code pointless?
[11:40:47] <altendky> 11:33 <altendky> but probably what Avaris pointed out is part of why i just walked away. if the signal is just some separate thing then whatever, i can make it entirely separate and toss it on a class that holds just signals etc. and then i don't have to dynamically create a class
[11:40:53] <altendky> 11:33 <altendky> the code that relates c.a with c.a_notify could as well relate c.a with c.signals.a_notify.
[11:40:58] <altendky> 11:34 <altendky> then the original class can stay intact and we just create a signal holder class separately
[11:41:03] <ali1234> oh
[11:41:06] <ali1234> timestamps
[11:41:10] <ali1234> i thought you meant line numbers
[11:41:20] <ali1234> you know the timestamps on my client are different :)
[11:41:39] <altendky> hence i used :32 not 11:32
[11:41:52] <altendky> but sure, people don't do that for some reason
[11:41:57] <altendky> maybe hh:32 would work better
[11:41:57] <Avaris> there are weird timezones :)
[11:41:59] <ali1234> ironically i probably would have understood if you used a full time, even though its a different timezone
[11:42:09] <altendky> Avaris: true. ugh
[11:42:29] <altendky> i want to write up a jimmy buffet time zone where it's always five o'clock
[11:43:03] <ali1234> i still don't understand whether it works or not though
[11:43:10] <altendky> ali1234: it works, doesn't it?
[11:43:17] <altendky> it's just more complicated than it needs to be
[11:44:35] <ali1234> hmm
[11:44:44] <ali1234> but say i want two properties
[11:44:59] <ali1234> then i have to declare a_notify and b_notify and stuff both into the type call
[11:45:46] <altendky> ali1234: yes. but you will generate that list from the existing attrs class
[11:45:53] <altendky> i'm working on the next layer of abstraction here
[11:45:54] <ali1234> yes, i see
[11:47:12] <ali1234> it occurs to me that this is going to end up like the registry pattern again
[11:47:12] <altendky> by tossing all this generated stuff off into an attribute you don't have to worry about copying over the existing methods defined in the class. you don't have to worry about namespace collisions with hand-coded stuff.
[11:48:57] <ali1234> btw the way i sidestepped this whole pattern is by just pulling objects directly out of the QML
[11:49:14] <ali1234> since they are declared in QML, they already have signals ready to go
[11:49:30] <ali1234> and everything just works
[11:50:10] <ali1234> i won't be able to do that for the menus though,. unless i can use a UI file?
[11:50:17] <ali1234> .ui i mean
[11:50:59] <altendky> https://repl.it
[11:51:20] <altendky> so now we could pull `names` from attr.fields(ExistingClass)
[11:51:24] <Avaris> not sure if designer has a way of creating just a menu (designer not my specialty)
[11:51:35] <ali1234> shouldn't main() return c or something?
[11:51:45] <altendky> ali1234: we haven't gotten to that point yet
[11:51:52] <altendky> but sure, main would become a decorator
[11:52:00] <ali1234> ah!
[11:52:08] <ali1234> i have to admit this is all very clever
[11:53:38] * Avaris waiting for a dynamic __init__ :)
[11:53:39] <altendky> it's almost like a spent several days exploring exactly this. :] and learning to hate the magic
[11:53:48] <altendky> Avaris: attrs will already provide that
[11:54:07] <altendky> but we do need an __attrs_post_init__ for the super call
[11:54:37] <altendky> i should probably finish this out. i don't know what i want but i am pretty sure i don't like exactly what i have in my lib
[11:55:05] <altendky> the problem we haven't touched is guessing which attributes/methods we need to copy from the original. which is where you get to 'just make a signal holder class' if possible
[11:55:21] <altendky> but qml needs may cause trouble with that approach
[11:55:23] <ali1234> i'm actually starting to understand this
[11:55:37] <altendky> ali1234: i didn't believe it was too complicated for you :]
[11:55:45] <altendky> just not obvious
[11:56:42] <altendky> we might be able to do something useful by inheriting from the original class. not my preferred direction in general but we already have inheritance and a metaclass and descriptors... what's another layer if it saves guessing on what to copy
[11:56:53] <altendky> alrighty, i'll add an attrs class next
[11:57:10] <ali1234> yeah this is where you need a special object type in the original class like _CountingAttr wasn't it?
[11:57:32] <altendky> ali1234: handily, attrs already does this for you
[11:58:51] <ali1234> what if there's just a dict pre-defined on the original class
[11:59:07] <ali1234> like _qprops = {'foo': int, ...}
[11:59:08] <altendky> ali1234: why would you do that instead of attrs?
[11:59:15] <altendky> i mean you could but...
[11:59:16] <ali1234> it seems like it would be simpler
[11:59:25] <altendky> ali1234: not really plus you lose attrs
[11:59:42] <ali1234> not really a problem
[11:59:49] <altendky> i like attrs
[11:59:54] <ali1234> i'm making a singleton, i don't need __eq__
[11:59:54] <altendky> it gets me all the other stuff
[12:00:08] <ali1234> this is like my QMainWindow
[12:00:09] <altendky> let's solve a general problem :]
[12:00:18] <ali1234> let's shave *all* the yaks
[12:00:31] <altendky> just wait, attr.fields() should give us everything we need
[12:03:03] <altendky> we've got enough magic already to make it conditional on attr.has()
[12:07:45] <altendky> hmm, little hiccup where the constructor tries to emit the signal before the super call has happened :]
[12:11:33] <altendky> ali1234: https://repl.it so `class C` and `main` are the only pieces an 'application' would have. the rest would be library.
[12:12:04] <ali1234> nice
[12:12:42] <ali1234> what happens if i inherit from C?
[12:12:57] <altendky> ali1234: just the same as if you had hand coded it
[12:13:10] <altendky> the special is all in the processing, not the result
[12:13:15] <ali1234> so the new class doesn't have auto attributes?
[12:13:54] <altendky> you would @propertize it. if you want new attributes to get the special treatment. i'm sure there are some nuances. give it a try
[12:14:17] <ali1234> why not put the @attr.s inside propertize?
[12:14:19] <altendky> and presently that would override the existing properties which probably isn't great. but i think might work fine
[12:14:26] <altendky> ali1234: like swap the two lines?
[12:14:29] <altendky> or combine into one function
[12:14:37] <ali1234> no like call attr.s() manually inside propertize
[12:14:51] <ali1234> seems like it is required anyway
[12:14:54] <altendky> you could. then you hide it and have to pass parameters through etc. but sure, maybe you want that
[12:15:24] <Avaris> isn't there a pre_init?
[12:15:41] <altendky> this reduces the interaction with attrs to attr.fields(). our code doesn't need to be at all aware of the attr.s parameters etc
[12:16:18] <altendky> Avaris: not that i'm familiar with. we could effectively build one in propertize and replace __init__ while calling the existing one. my 'real' code does that
[12:17:22] <ali1234> hmmmmmmmm
[12:18:57] <ali1234> i think i can see how to do this in a much simpler way
[12:19:16] <Avaris> that's unfortunate
[12:21:33] <ali1234> the signal has to exist when the metaclass runs. but nothing says it can't be created after that if we make a whole new class
[12:22:13] <Avaris> huh?
[12:24:04] <ali1234> altendky: the third argument of type... you can extract that dict from an existing class, correct?
[12:24:51] <ali1234> so make the class in the usual way. declare the signal after the metaclass has run. who cares? then just use type to make an exact copy of that class, without having to look into it
[12:25:24] <altendky> ali1234: I thought the point was to create all this boilerplate
[12:26:37] <ali1234> the above also removes all the boilerplate
[12:27:06] <altendky> ali1234: how does writing the property and signal manually remove the boilerplate?
[12:27:14] <altendky> It exactly is the boilerplate
[12:27:16] <ali1234> you dont do it manually
[12:27:27] <ali1234> you do it with a function
[12:27:31] <altendky> ali1234: code it up I guess
[12:27:41] <altendky> Because that's literally what I have isn't it?
[12:27:54] <ali1234> no, it is slightly different
[12:28:08] <ali1234> you convert what is in the original class definition
[12:28:24] <ali1234> i put exactly what i want in the original class, and then rebuild it verbatim so that it actually works
[12:28:33] <altendky> Code it up
[12:28:37] <ali1234> it is very very similar, yes
[12:28:42] <ali1234> but subtly different
[12:28:50] <altendky> I don't understand what more it is that I would want to write in the original class
[12:28:57] <ali1234> it isn't more, it is less :)
[12:29:30] <altendky> ali1234: how do you describe an attribute in less that `a: int`?
[12:29:55] <ali1234> how do you know whether that is supposed to be a property or not?
[12:30:31] <altendky> ali1234: this assumes it should be. You could add some metadata through attrs
[12:31:36] <ali1234> i'll code it
[12:31:58] <ali1234> it probably won't work for some reason i have not thought of
[12:32:37] <ali1234> but if it does then you'll only have a wrapper around pyqtProperty with identical semantics and a class decorator that is a single call to type()
[12:33:09] <ali1234> and no requirement to use attrs unless you want to
[12:33:13] <altendky> ali1234: you mean 'not use attrs'? i mean, i want to use attrs. that's how i want to define a class
[12:33:35] <altendky> and writing `a = mypropertything(int)` will be strictly more, not less
[12:33:59] <ali1234> unless you want the ability to have attributes that aren't properties
[12:34:08] <ali1234> then it will be roughly the same amount
[12:34:12] <ali1234> but less support code
[12:34:17] <altendky> ali1234: why are they specified in the class scope?
[12:34:41] <ali1234> i don't know?
[12:34:48] <ali1234> where else would you declare them?
[12:34:56] <altendky> except you'll still have to go and write your setter and getter if that's what you imagine saving
[12:35:10] <altendky> ali1234: you generally def __init__(self): self.a = 37
[12:35:33] <altendky> ali1234: how about this, start with writing how you would like to write the class
[12:35:44] <altendky> we can look at that as you write the rest of the implementation
[12:36:39] <Avaris> out of curiosity, how many qt properties will you define? :)
[12:36:46] <ali1234> like 20 or so
[12:37:15] <altendky> my models are attrs classes with every column/field being a property (i don't even remember if it's a pyqt property or a regular one)
[12:37:36] <altendky> given the manual signal emission a regular property becomes more sufficient (as i'm not doing qml (yet?))
[12:37:41] <ali1234> open your favorite text editor, look at how many options it has in the menus, that many
[12:38:12] <Avaris> menu... property... could not correlate
[12:38:45] <altendky> menu items relating to values set elsewhere. like the radio stuff i suppose
[12:38:55] <ali1234> okay then, look at how many properties a QTextedit has, that many
[12:39:10] <altendky> that seems unrelated beyond being a number
[12:39:13] <altendky> but whatever
[12:39:25] <altendky> i'm still curious how the class is going to be written more concisely
[12:39:28] <ali1234> altendky: to answer your question, i would like to define properties like this: a = pyqtProperty(int, notify=True)
[12:40:09] <altendky> ali1234: so you literally _do_ want to write the property. just not the getter and setter?
[12:40:15] <ali1234> or the signal
[12:40:23] <ali1234> yes, exactly
[12:40:37] <altendky> i like the consistency of not doing that
[12:40:41] -!- yustin_ has joined #pyqt
[12:40:55] <ali1234> i do also want the ability to write the getter and the setter by using pyqtProperty as a decorator, like @property
[12:40:59] <altendky> if there's _that_ much overhead due to an unneeded property then type a little extra to make it not a property
[12:41:01] <ali1234> but again, i do not want to declare the signal
[12:41:10] <altendky> gee golly
[12:41:24] <altendky> so you literally just want the signal generated? you are going to write the setters and getters too?
[12:41:47] <ali1234> sometimes i will write them, sometimes i wont
[12:41:51] <altendky> like, just don't touch the original class and put them somewhere else on a dedicated signals attribute
[12:42:25] <altendky> aren't we back to a more verbosely written version of what's in my lib with the optional overrides?
[12:42:31] <ali1234> i like the clarity of knowing exactly what a is
[12:42:51] <altendky> but not what the signal is...
[12:42:54] -!- yustin has quit [Ping timeout: 240 seconds]
[12:42:59] yustin_ is now known as yustin
[12:43:19] <ali1234> well in the case of QML i dont need to know what the signal is because QML will automatically figure it out
[13:05:26] <ali1234> well i coded it but it didn't work
[13:06:44] <ali1234> wait
[13:07:37] <ali1234> no! it actually works!
[13:07:47] <ali1234> altendky: https://repl.it
[13:08:24] <ali1234> this is exactly what i wanted all along :)
[13:09:03] <ali1234> but wait... it still works even without the class decorator
[13:09:18] <ali1234> and i don't understand why
[13:09:49] <altendky> .a_notify won't exist so it won't work
[13:09:56] <altendky> well, that exact code
[13:10:11] <ali1234> yes it will
[13:10:22] <ali1234> but it will have been created after the metaclass runs, so it should not fire properly
[13:10:25] <altendky> oh right, your descriptor
[13:10:34] <altendky> that goes and mutates the host class...
[13:10:39] <ali1234> yes
[13:10:53] <ali1234> but nobody will ever see it because it is wrapped in a decorator
[13:11:32] <ali1234> i mean it will be impossible to know that the orignal class even existed, so who cares what we do to it?
[13:11:37] <altendky> welp, that is an interesting pre-metaclass hook
[13:11:58] -!- BPL has quit [Ping timeout: 256 seconds]
[13:11:58] <ali1234> __set_name__ is pre-metaclass?
[13:12:20] <altendky> that's the only way this would work without the decorator, right? but maybe i'm wrong
[13:12:27] <ali1234> i guess so
[13:12:34] <ali1234> but i have not tested this with QML
[13:12:38] <ali1234> maybe it does not work properly there
[13:12:50] <ali1234> i tested something similar to this before and it did not work, but i maybe had bugs
[13:13:35] <ali1234> also if you don't like that this creates _a and a_notify automatically, they can of course be made into optional arguments of PyQtProp
[13:13:40] <ali1234> strings for their names i mean
[13:13:42] -!- BPL has joined #pyqt
[13:16:10] <ali1234> also i should probably call super in all those methods just in case
[13:16:17] <ali1234> but yeah this is what i was trying to describe before
[13:29:25] <ali1234> wow i made repl.it SIGSEGV
[13:29:39] <ali1234> that's bad right?
[13:34:05] <ali1234> i just tried to use my PyQtProp like a decorator
[13:34:28] <altendky> it means you made qt crash. i mostly do it with indexes and the wrong model
[13:34:41] <altendky> presumably because of terrible habits in that area
[13:42:51] <ali1234> what happens if you use getattr(x, '__name')?
[13:42:56] <ali1234> what does it get mangled to?
[13:43:07] <ali1234> does it even?
[13:43:36] <ali1234> wondering if this would be a good situation to use it, to avoid collisions with whatever else user declares in their class
[13:43:38] <altendky> i don't know
[13:43:56] <ali1234> if it mangles to _PyQtProp_name then that would be pretty good i think
[13:44:39] <ali1234> i suppose i could just make it be that manually
[13:44:47] <altendky> i like putting all my secret stuff in one place, fwiw. one attribute ala what attrs does. and maybe making it not __ but _mypkg_module_MyClass or somesuch so there's some sense of where it came from and also some sense of 'ownership' of that name
[13:45:34] <altendky> and using mylib.getstuff(instance) rather than instance._magical_place_for_me let's you keep the latter as an implementation detail
[13:46:07] <ali1234> well, but the signal has to be bound to the class, or else you need a huge amount of support code to make it work
[13:46:18] <ali1234> bound to the instance i mean
[13:46:44] <altendky> mine aren't, but maybe the qml/property stuff requires it
[13:47:11] <ali1234> probably not, but you have to maintain a lot more code to make yours work :)
[13:48:36] <altendky> i bet most people will be surprised to find your descriptor adding more attributes to the class :|
[13:49:08] <ali1234> probably, yes, but then anything you write in class scope adds stuff to the class
[13:49:16] <altendky> magic at the bottom breeds more magic all the way up
[13:49:26] <altendky> ali1234: no, it doesn't. assignments do
[13:49:37] <ali1234> that type of thing is exactly what i wanted to avoid
[13:49:52] <ali1234> hence why usage of my thing looks exactly like usage of the base pyqtProperty
[13:49:57] <altendky> but each step you are embracing more of it :]
[13:50:04] <ali1234> there is only one step tho
[13:50:09] <altendky> 'looks like' usually means more magic, not less
[13:50:23] <ali1234> also
[13:50:39] <ali1234> they should not be surprised that it add a_notify, when the whole point of it is to add that :)
[13:51:00] <altendky> people reading the code will be surprised. pretty sure that'll just be fact
[13:51:02] <ali1234> and also also, yours does the same thing
[13:51:20] <altendky> maybe `a, a_notify = whatever()` would be better if that works in class scope?
[13:51:22] <ali1234> it just takes more lines of code to do so
[13:51:34] <altendky> ali1234: less surprising out of a decorator, but sure.
[13:51:38] <ali1234> wouldn't that require the class to be a tuple?
[13:51:51] <altendky> the thing returned by whatever would have to be iterable
[13:51:58] <altendky> the first thing being the property and the second being the signal
[13:52:00] <ali1234> yeah
[13:52:04] <altendky> not yeah
[13:52:08] <ali1234> but then how would __set_name__ work?
[13:52:13] <altendky> a layer around to get rid of the magic
[13:52:22] <altendky> mm...
[13:52:27] <ali1234> i suppose it would be called on the two things individually
[13:52:33] <altendky> is it still needed?
[13:52:35] <ali1234> i think this could work
[13:52:47] <ali1234> well there is still the matter of _a
[13:53:03] <altendky> that's an attribute instance, right?
[13:53:11] <ali1234> and also the property needs to know the name of the signal on the object in order to call it
[13:53:12] <altendky> so no need for it to take place then
[13:53:23] <altendky> that's inside `whatever`
[13:53:28] <ali1234> no, it isn't
[13:53:40] <ali1234> because whatever doesn't know the class you are running it on without __set_name__
[13:53:42] <altendky> it would be here
[13:54:02] <altendky> i just pass the bare function to my notify=
[13:54:07] <ali1234> yes
[13:54:11] <ali1234> but how do you emit it?
[13:54:13] <altendky> as i recall
[13:54:20] <altendky> i mean my code is right there :]
[13:54:47] <ali1234> you calculate the signal name and store it
[13:54:59] <altendky> 'store it'?
[13:55:10] <altendky> a closure i guess it was
[13:55:11] <ali1234> yes, in a closure
[13:55:21] <altendky> yeah, the closures aren't my favorite piece ever
[13:55:31] <ali1234> but if it is like a, a_notify = whatever() then whatever doesn't know the name!
[13:55:45] <ali1234> it runs before the result even gets bound to a name
[13:55:57] <ali1234> so you can't avoid __set_name__ somehow
[13:56:02] <altendky> i'm still not quite getting the difference
[13:56:04] <ali1234> but it can still work
[13:56:16] <altendky> all my methods and signals and properties were made before the class, right?
[13:56:18] <ali1234> code it :)
[13:56:25] <altendky> mm, but they had the name
[13:56:33] <ali1234> yes but you were explicitly given the name
[13:56:44] <altendky> i mean i already spent hours writing you stuff based on what you had said you wanted and it wasn't what you wanted so... :|
[13:57:12] <altendky> but at least it lead you somewhere you wanted
[14:01:45] <ali1234> it seems like you are suggesting something like this: https://repl.it
[14:01:48] <ali1234> notice all the ???
[14:02:05] <altendky> 13:56 <altendky> mm, but they had the name
[14:02:05] <altendky> ?
[14:02:14] <ali1234> who had the name?
[14:02:24] <altendky> my stuff, i acknowledged the issue
[14:02:29] <ali1234> all your methods, yes
[14:02:49] <altendky> though it could be made up and unrelated to the name perhaps if it's really private and not used by anything else
[14:02:50] <ali1234> ah okay
[14:03:12] <altendky> uuids, global counter, whatever. maybe?
[14:03:17] <ali1234> i still think it could be done, but it would have to return two descriptor objects both with __set_name__
[14:03:28] <ali1234> and they would have to know about eachother
[14:03:46] <ali1234> but it might be worth it just to reduce the magic
[14:04:26] <altendky> ali1234: just create a uuid as the name? _mypyqtpropertymagic_uuid_090409009810340913094. or as mentioned a global counter.
[14:04:44] <ali1234> i kind of like the idea of making the signal name explicit though
[14:05:06] <altendky> so not private
[14:05:20] <ali1234> it can't be private if anyone ever wants to connect to it (outside of QML auto binding)
[14:07:11] <ali1234> imean there's two things here, the signal name, and the back store of the actual data
[14:07:21] <ali1234> former must be public, latter should be private
[14:11:52] <altendky> hmm, seems to work https://repl.it
[14:12:31] <ali1234> yep, logically it should work. making them aware of each other might be tricky... i'm trying to code it now
[14:13:06] <altendky> hey, another nasty trick, nonlocal the variable and assign to it in __set_name__?
[14:14:03] <altendky> https://repl.it for reference it's processed at class creation not assignment so the way in which it gets assigned is reasonably irrelevant it seems
[14:17:33] -!- ali1234 has quit [Ping timeout: 272 seconds]
[14:27:56] -!- ali1234 has joined #pyqt
[14:28:01] <ali1234> i am back
[14:28:12] <ali1234> this is what i came up with: https://repl.it
[14:28:23] <ali1234> however it does not work because pyqtSignal does not appear to be a class
[14:28:58] <ali1234> it should work apart from that :)
[14:29:00] <altendky> pyqtUnboundSignal or somesuch
[14:29:33] <altendky> just type(PyQt5.QtCore.pyqtSignal())
[14:29:41] <altendky> (to see what it is)
[14:30:31] <ali1234> PyQt5.QtCore.pyqtSignal
[14:30:42] <altendky> doesn't seem right
[14:30:45] <ali1234> so it is a class, you just can't inherit from it?
[14:31:37] <altendky> do you really need to inherit from them at all?
[14:31:51] <altendky> just make your own descriptor that gives back instances of the proper thing?
[14:31:55] <ali1234> well, it is easier than delegating every method
[14:32:13] <ali1234> hmm that could work
[14:32:16] <altendky> you control __get__. give back what __get__ on the underlying does
[14:32:41] <altendky> i think that's what i did here https://github.com
[14:34:33] <altendky> well, i guess i had them on another object so just o.signal did it. but you can still call __get__ on them and pass through. so you only pass the descriptor protocol, not all of their methods
[14:41:28] <ali1234> i have this and it gives a very straneg error i do not understand https://repl.it
[14:41:51] <ali1234> TypeError: the notify signal 'int)' was not defined in this class
[14:42:06] <altendky> it's good to fork (after you wait until it saves) then share that (then remember to go back before editing)
[14:42:24] <altendky> basically, repl.it made this worse a few years back :[
[14:42:47] <ali1234> where is that ) coming from??
[14:43:06] <altendky> probably misinspection of code or something i'd guess. looking
[14:43:29] <altendky> also, put your code in a function and call it :] rather than if __name__.
[14:44:05] <ali1234> pycharm needs the in __name__ in order to produce a run button
[14:44:22] <altendky> you aren't passing through for __set_name__ for one on the signal
[14:44:28] <ali1234> it doesn't have one
[14:44:30] <ali1234> i checked
[14:44:30] <altendky> nor the prop
[14:44:33] <altendky> mm
[14:44:38] <ali1234> ditto afaik
[14:44:43] <altendky> and no need to inherit from object
[14:44:47] <ali1234> but the prop code is basically the same as previous version, and that worked
[14:45:48] <altendky> the metaclass is probably bypassing the descriptor or somesuch
[14:46:03] <altendky> hmm
[14:47:03] <ali1234> hmm what if i just overwrite the attribute with the real signal
[14:47:12] <altendky> 'real'?
[14:47:29] <ali1234> setattr(owner, name, self._signal)
[14:47:43] <ali1234> result: SIGABRT
[14:50:53] <ali1234> hmm
[14:51:52] -!- sazawal has quit [Ping timeout: 260 seconds]
[14:52:09] <ali1234> i guess the magic is too deep
[14:52:18] <altendky> that's giving up pretty quick...
[14:53:17] <ali1234> before i had something working like a_notify = pyqtSignal(); a = prop(int, a_notify, 'a_notify')
[14:53:27] <ali1234> and prop would just make the get/set
[14:53:42] <ali1234> i didn't like having to repeat the signal name twice
[14:53:56] <ali1234> but maybe i could get around that in __set_name__
[14:54:29] <ali1234> where is the fork button on repl.it?
[14:55:57] <altendky> sorry, the pencil icon brings up a 'window' with fork in it
[14:56:04] <altendky> pencil icon next to the name at the top in the middle
[14:57:02] <ali1234> i dont see it. is it because i am not signed it?
[14:57:36] <ali1234> yes, it is
[15:02:00] <ali1234> nope, SIGABRT again
[15:03:10] <ali1234> hmm i think i know why
[15:04:35] <ali1234> aaa
[15:04:46] <ali1234> i'm dumb, i should read the error more carefully
[15:05:25] <ali1234> this works https://repl.it
[15:10:08] -!- frispete_ has quit [Ping timeout: 265 seconds]
[15:11:18] -!- sazawal has joined #pyqt
[15:13:12] <ali1234> hmm there is actually no need to defer __init__ in the old version
[15:14:52] <ali1234> https://repl.it
[15:15:45] <ali1234> i should test whether this works with QML
[15:29:04] <ali1234> doesn't work
[15:30:10] <ali1234> not even with the autoprop decorator
[15:30:32] <ali1234> let me try yours
[15:34:37] <ali1234> nope, yours doesn't work either: TypeError: invalid result from TTModel.data(), unable to convert a Python 'TTChar' object to a C++ 'QObject*' instance
[15:39:55] <altendky> what are TTModel and TTChar
[15:40:19] <ali1234> TTModel is a QAbstractListModel and TTChar is what TTModel.data() returns
[15:40:41] <altendky> i don't follow how that has anything to do with what we are doing?
[15:41:12] <ali1234> when you make a QML view and set its model to the TTModel, each delegate will have access to the objects inside it
[15:41:35] <ali1234> when a delegate does something like text: display.text, that meqans use the text property on that TTChar object
[15:41:55] <ali1234> when python changes the text value in the TTChar, due to QML binding, the delegate will update automatically
[15:42:08] <ali1234> if you make the properties by hand using pyqtProperty in the normal way, this all works fine
[15:42:20] <ali1234> with the stuff i made it doesn't work - nothing happens
[15:42:28] <ali1234> with yours, the object cannot even be converted to C++
[15:42:48] <altendky> so TTChar is a class decorated with @propertize?
[15:42:51] <ali1234> yes
[15:42:57] <altendky> in the 'my code' case
[15:42:58] <ali1234> and the attrs thing
[15:43:20] <altendky> can you share the full code?
[15:43:33] <ali1234> sure, it is on github, let me find the right ref
[15:44:49] <ali1234> here is TTChar with semi-manual properties
[15:44:50] <ali1234> https://github.com
[15:46:13] <ali1234> (that version fully works as expecte)
[15:46:27] <ali1234> this is the attrs version
[15:46:29] <ali1234> https://github.com
[15:46:44] <altendky> you don't have the post init
[15:47:18] <altendky> there's a ticket for attrs regarding ... maybe an option or something to super for you
[15:47:30] <ali1234> post init added, result is identical
[15:47:40] <altendky> link? :]
[15:48:02] <ali1234> just reload the one above since it points to master and i pushed :)
[15:48:08] <ali1234> HEAD sorry :)
[15:48:13] <ali1234> (of that branch)
[15:48:18] <altendky> got it
[15:49:28] <altendky> i dunno. i'll have to mull that over a bit
[15:50:33] <ali1234> i guess mine doesn't work because __set_name__ does not come before the metaclass
[15:50:41] <ali1234> or something like that
[15:50:57] <ali1234> this is a tricky problem
[15:51:09] <altendky> maybe try a trivial `TTChar = type('TTChar', (TTChar,), {})` on your manual TTChar to see if that breaks it
[15:51:18] <altendky> just a pointless inheritance
[15:51:57] <ali1234> same
[15:52:05] <ali1234> WAIT
[15:52:15] <ali1234> not the same, it did something different this time
[15:52:45] <ali1234> okay i am dumb again
[15:52:54] <ali1234> adding the post init fixed it
[15:52:57] <ali1234> it works :)
[15:53:18] <ali1234> i had declared text: int accidentally
[15:54:54] <altendky> welp, even if not the form you want it's a point of reference to bisect against
[15:57:05] -!- ali1234 has quit [Remote host closed the connection]
[15:58:49] -!- ali1234 has joined #pyqt
[16:00:20] -!- sazawal has quit [Quit: Leaving]
[16:02:41] <ali1234> don't know if you saw that, but yours actually works with the attrs post init in place
[16:03:31] <ali1234> i thought i understood how yours works, and i thought my autoprop trick was equivalent, but obviously that is not true, because it does not help
[16:07:11] <ali1234> QML cannot see the properties at all
[16:07:19] <ali1234> but connecting to them in python works
[16:07:36] <altendky> 15:54 <altendky> welp, even if not the form you want it's a point of reference to bisect against
[16:07:43] <ali1234> yes
[16:08:07] <ali1234> type(C.__name__, C.__bases__, dict(C.__dict__)) - is this actually right?
[16:08:26] <ali1234> it should make an identical copy of C that isn't C
[16:08:27] <altendky> i chose to inherit rather than copy to avoid thinking about the nuances of what to copy and what not to
[16:08:57] <ali1234> if i just copy everything i don't see why it wouldn't work (and it does work, just only in python)
[16:09:18] <altendky> "nuances" ? i dunno. might be nothing there, might be something there
[16:10:10] <ali1234> have you still got the link to the version that doesn't use attrs?
[16:10:38] <altendky> it'll just be a lower number at the end i'd have to dig back through
[16:10:48] <altendky> if you mean my early repl.it's today
[16:11:00] <ali1234> yeah i'll find it...
[16:11:56] <ali1234> i think something happens to the pyqtSignal when it is bound to an object. something permanent somehow
[16:12:05] <ali1234> probably related to why you can't subclass it
[16:12:58] <ali1234> yours really isn't all that different to mine except for the use of attrs
[16:13:07] <ali1234> and directly using type
[16:14:54] <ali1234> what i mean is, in yours when the signal is passed to type, it hasn't previously been attached to a class. in mine it has
[16:27:45] <ali1234> hmm. made it work without attrs, just using a dict with the properties
[16:36:12] <altendky> sounds like there was more being copied than we wanted?
[16:36:27] <ali1234> no
[16:37:00] <ali1234> the issue seems to be that once you have run init on a class with a signal, that signal object becomes unusable in any other class
[16:37:08] <ali1234> so you can't copy it from one class to another with type()
[16:37:18] <ali1234> you have to construct the dict for type() from scratch
[16:37:22] <altendky> that seems odd
[16:37:32] <altendky> even just that you were creating an instance of a class then moving the signal
[16:37:44] <ali1234> i never created an instance
[16:37:55] <altendky> then you didn't run __init__
[16:38:12] <ali1234> well, okay then, something with the metaclass stuff
[16:38:15] <altendky> and isn't constructing the dict from scratch exactly not copying some stuff?
[16:38:26] <ali1234> yes
[16:38:35] <altendky> 16:36 <altendky> sounds like there was more being copied than we wanted?
[16:38:51] <ali1234> no, because copying everything was the intention
[16:38:55] <ali1234> it just turns out it doesn't work
[16:39:19] <altendky> are you sure you wanted to copy all the regular __'s you probably haven't even heard of?
[16:39:31] <ali1234> sure, why not?
[16:39:53] <altendky> you at least haven't seemingly shown that isn't part of the issue
[16:39:56] <ali1234> they should be just as good as any other
[16:40:09] <altendky> 'i copied less and it worked therefore copying too much is not the problem'
[16:40:16] <ali1234> i didn't copy less
[16:40:19] <altendky> you did
[16:40:23] <ali1234> i copied 0
[16:40:41] <altendky> yes. instead of copying everything you didn't copy and constructed just a few specific new things
[16:40:47] <altendky> which would exactly be none of the dunders
[16:41:01] <altendky> so you've shown nothing about how copying those dunders did not cause trouble
[16:41:06] <ali1234> hmm okay then let me try something
[16:41:07] <altendky> maybe they didn't, but you haven't shown it
[16:41:48] <altendky> but inheriting and adding seems _way_ simpler. also consider if you build only a dict for type with the signals you want, you will lose any custom methods you add
[16:44:54] <ali1234> type(C.__name__, C.__bases__, {k: v for k, v in C.__dict__.items() if not k.startswith('__')})
[16:45:03] <ali1234> same result
[16:45:13] <ali1234> it works in python, QML cannot see the properties at all
[17:00:04] -!- frispete_ has joined #pyqt
[17:02:41] -!- ali1234 has quit [Remote host closed the connection]
[17:05:45] -!- ali1234 has joined #pyqt
[17:14:50] -!- frispete_ has quit [Ping timeout: 265 seconds]
[17:22:52] -!- frispete_ has joined #pyqt
[17:39:42] <altendky> ali1234: so we're back to guessing. if you write a __repr__ you'll lose it. right?
[17:40:26] <ali1234> yes, but i didn't
[17:40:42] <altendky> yes, but i'm pointing out an issue with that approach
[17:40:51] <altendky> why not just inherit and add what you want? (if anything) (or maybe i'm off in the wrong direction for the present issue, but still)
[17:40:53] <ali1234> you asked for proof it was not related to copying dunders
[17:41:02] <altendky> mm, sorry
[17:41:20] <altendky> i thought there were bigger issues than 'qml not seeing properties' before
[17:41:37] <altendky> like an actual error
[17:41:37] <ali1234> no, all of the methods work fine as long as the object is only used in python
[17:42:20] <ali1234> as soon as you pass them through to QML, copying methods fail. methods that create totally new signals and properties work
[17:42:52] <altendky> i'm going after various things i want to be different in my next python+qt app. trio and pyside anyways. i should probably consider adding qml to that list. so maybe i'll get to poking at that more at some point.
[17:43:43] <altendky> i'm not quite following. why are you copying methods? is there a reason to not use type for inheritance and addition instead of copying?
[17:43:55] <ali1234> i expect the failure is at the python/C++ boundary, not specifically QML
[17:44:05] <ali1234> but i have no way to test that
[17:44:15] <ali1234> i am not copying methods
[17:44:37] <altendky> "copying methods fail" misreading of that
[17:45:00] <altendky> anyways... you say copying doesn't work. but you have to? mine doesn't, right?
[17:45:04] <ali1234> here "method" means an algorithm or sequence of operations, not a class method
[17:45:19] <ali1234> no, i don't have to copy
[17:45:28] <ali1234> i am just observing that it doesn't work
[17:45:48] <altendky> well that's good :]
[17:49:25] -!- yustin has quit [Ping timeout: 264 seconds]
[18:04:06] -!- totte has quit [Ping timeout: 260 seconds]
[18:18:03] -!- totte has joined #pyqt
[18:27:23] -!- lastrodamo has joined #pyqt
[18:32:23] -!- lastrodamo has quit [Quit: Leaving]
[18:45:43] <ali1234> weird. the order of the items in the type dict seems to affect whether it works or not
[18:47:42] <ali1234> hmm, nope, that's not it
[18:56:06] <ali1234> finally, an implementation that works with QML: https://repl.it
[18:56:21] <ali1234> the functions that pass are to make pycharm not complain
[18:58:04] <ali1234> also, no descriptors
[18:58:40] <ali1234> well, except the normal pyqtProperty
[19:11:11] -!- JanC has quit [Remote host closed the connection]
[19:11:28] -!- JanC has joined #pyqt
[20:06:33] -!- BPL has quit [Quit: Leaving]
[21:10:39] -!- Belxjander has quit [Quit: AmigaOSv4.1.6+//PowerPC native]
[21:13:01] -!- Belxjander has joined #pyqt
[23:01:04] -!- Belxjander has quit [Ping timeout: 256 seconds]
[23:10:56] -!- Belxjander has joined #pyqt
[23:19:17] -!- plutopotamus has joined #pyqt