<div dir="ltr">Hi Shaheed,<br><br><div class="gmail_quote"><div dir="ltr">Shaheed Haque <<a href="mailto:srhaque@theiet.org">srhaque@theiet.org</a>> schrieb am Fr., 3. Nov. 2017 um 14:16 Uhr:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Philipp,<br>
<br>- my overall understanding of this technique is that it may end up<br>
being fragile, especially given the difference between P2 and P3.<br></blockquote><div><br></div><div>Python 2? I’m sure we shouldn’t include into our decision making an obsolete language that has a final (yes, really this time!) expiration date 2 years in the future. 2020 is the end of the line, I certainly don’t bother anymore to write a single line accomodating to it, and would suggest you do the same for a new project.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- using it further down might not work as expected especially if there<br>
are "accidental" collisions in the directory/namespace names.<br>
- it is also not clear if the technique can be used multiple times.<br></blockquote><div><br></div><div>We should check if this is the case. Who’s a Python guru who knows the ins and outs of the module system?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- cppyy gives us classes. (Actually, in conversation with Wim, CC'd<br>
here, it turns out that the choice of using classes is not arbitrary,<br>
but we were pondering simple modules at that point, for other<br>
reasons).<br></blockquote><div><br></div><div>I’d be interested in why. Usually using classes as namespaces is only done for reasons of cuteness (callable namespaces, namespaces usable as context managers, …) or so.</div><div><br></div><div>Even in this case, it’s possible to replace the module’s class with a module subclass that has the necessary capabilities (modules are objects that have a class, too)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Bottom line: I'm not keen on using Python namespace modules here for<br>
the reasons listed.<br></blockquote><div><br></div><div>I’m not entirely convinced. We should only do a final decision once we know if either your suspicions of multiple levels not working turn out to be true, or the reason for using classes is important.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That's likey to be a bad idea because of the potential impact on arbitrary round trips between C++ and Python (remember that everything is based on named-based lookups). In addition, we already have problems like "gpgme++", and the use of capitalisation to separate legacy and forwarding headers in KDE: further case-based confusion is the last thing that is needed!<br></blockquote><div><br></div><div>I see, makes sense. I guess the allcaps example here is not very common anyway, and most namespaces will be UpperCamelCase like Qt’s, right?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks for the review/remarks, Shaheed<br></blockquote><div><br></div><div>NP!</div><div>Best, Philipp </div></div></div>