Re: Abstraction level at which to create SQLAlchemy ORM object
Hi Cameron,
Cameron Simpson writes:
> On 10Feb2022 14:14, Loris Bennett wrote:
>>I am writing a command line program which will modify entries in a
>>database and am trying out SQLAlchemy.
>>
>>A typical command might look like
>>
>> um --operation add --uid ada --gid coders --lang en
>>
>>Parsing the arguments I get, ignoring the operation, a dict
>>
>> {uid: "ada", gid: "coders", lang: "en"}
>>
>>At some point this needs to be converted into an object of the class User:
>>
>> class User(Base):
>> __tablename__ = "users"
>>
>> uid = Column('uid', String, primary_key=True)
>> gid = Column('gid', String)
>> lang = Column('lang', String)
>>
>>In a way it seems it would be economical to do the conversion as early
>>as possible, so I can just pass around User objects. However, this
>>would mean that the entry point for the program would already be tightly
>>coupled to the specifics of the database interaction.
>>
>>On the other hand, delaying the conversion would mean probably having to
>>define my own User class, which seems like unnecessary overhead. It
>>would have the advantage that I could ditch SQLAlchemy more easily if I
>>find it too mind-bending.
>
> If the entire persistent state of the user lives in the db I'd just
> define the User ORM type and give it whatever methods you need. So
> exactly what you've got above.
>
> It is close to the db, but if you only interact via the methods and the
> core attributes/columns that should be mostly irrelevant to you.
>
> If you're concerned about switching backends, maybe define an
> AbstractUser abstract class with the required methods. Then you can at
> least ensure method coverage if you make another backend:
>
> class AbstractUser(ABC):
> @abstractmethod
> def some_user_method(self,...):
>
>
> class SQLAUser(Base, AbstractUser):
> ... your SQLA ORM User class above ...
>
> User = SQLAUser
>
> ... everything else just talks about user ...
>
> But you can do all of that _later_, only needed if you decide to change
> backends in a controlled manner.
Thanks for reminding me about abstract classes, but more importantly
that I can do this kind of stuff later.
Cheers,
Loris
--
https://mail.python.org/mailman/listinfo/python-list
Re: PermissionError: [Errno 13] Permission denied: 'Abc.xlsx'
On 2022-02-11 08:11:32 +1100, Chris Angelico wrote: > Excel doesn't have the sophistication to need or want anything more > than simple "I have this file, nobody else touch it" exclusive > locking. Interestingly, Excel did have the ability for multiple users editing the same file at some time (maybe early 2000s? Way before Google docs or Office 365). It had to be explicitely enabled and it didn't work very reliably (at least not with Samba as file servers), so we never really used it but it is clear that somebody at MS thought that users needed or at least wanted that ability. hp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | h...@hjp.at |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
Re: How do you log in your projects?
On Wed, 9 Feb 2022 19:38:23 +, Martin Di Paola wrote: >>> - On a line per line basis? on a function/method basis? > > In general I prefer logging line by line instead per function. > > It is easy to add a bunch of decorators to the functions and get the > logs of all the program but I most of the time I end up with very > confusing logs. > > There are exceptions, yes, but I prefer the line by line where the log > should explain what is doing the code. > >>> - Which kind of variable contents do you write into your logfiles? >>> - How do you decide, which kind of log message goes into which level? >>> - How do you prevent logging cluttering your actual code? > > These three comes to the same answer: I think on whom is going to read > the logs. > > If the logs are meant to be read by my users I log high level messages, > specially before parts that can take a while (like the classic > "Loading..."). > > If I log variables, those must be the ones set by the users so he/she > can understand how he/she is controlling the behaviour of the program. > > For exceptions I print the message but not the traceback. Across the > code tag some important functions to put an extra message that will > enhance the final message printed to the user. > > https://github.com/byexamples/byexample/blob/master/byexample/ common.py#L192-L238 > > For example: > > for example in examples: > with enhance_exceptions(example, ...): > foo() > > So if an exception is raised by foo(), enhance_exceptions() will attach > to it useful information for the user from the example variable. > > In the main, then I do the pretty print > https://github.com/byexamples/byexample/blob/master/byexample/ byexample.py#L17-L22 > > If the user of the logs is me or any other developer I write more > debugging stuff. > > My approach is to not log anything and when I have to debug something I > use a debugger + some prints. When the issue is fixed I review which > prints would be super useful and I turn them into logs and the rest is > deleted. > > > On Tue, Feb 08, 2022 at 09:40:07PM +0100, Marco Sulla wrote: >>These are a lot of questions. I hope we're not off topic. >>I don't know if mine are best practices. I can tell what I try to do. >> >>On Tue, 8 Feb 2022 at 15:15, Lars Liedtke wrote: >>> - On a line per line basis? on a function/method basis? >> >>I usually log the start and end of functions. I could also log inside a >>branch or in other parts of the function/method. >> >>> - Do you use decorators to mark beginnings and ends of >>> methods/functions in log files? >> >>No, since I put the function parameters in the first log. But I think >>that such a decorator it's not bad. >> >>> - Which kind of variable contents do you write into your logfiles? Of >>> course you shouldn't leak secrets... >> >>Well, all the data that is useful to understand what the code is doing. >>It's better to repeat the essential data to identify a specific call in >>all the logs of the function, so if it is called simultaneously by more >>clients you can distinguish them >> >>> - How do you decide, which kind of log message goes into which level? >> >>It depends on the importance, the verbosity and the occurrences of the >>logs. >> >>> - How do you prevent logging cluttering your actual code? >> >>I have the opposite problem, I should log more. So I can't answer your >>question. >>-- >>https://mail.python.org/mailman/listinfo/python-list In my current project I use the loggin module & write to a file I log at info level for the entry & exit of each function/method & scatter debug level logs for arease where I need to check data is as expected I have also found Ansi colour codes usefull when skiming through the output -- If an experiment works, something has gone wrong. -- https://mail.python.org/mailman/listinfo/python-list
Re: PermissionError: [Errno 13] Permission denied: 'Abc.xlsx'
On Fri, 11 Feb 2022 20:37:57 +0100, "Peter J. Holzer" declaimed the following: >Interestingly, Excel did have the ability for multiple users editing the >same file at some time (maybe early 2000s? Way before Google docs or >Office 365). It had to be explicitely enabled and it didn't work very >reliably (at least not with Samba as file servers), so we never really >used it but it is clear that somebody at MS thought that users needed or >at least wanted that ability. A quick Google does find mention of "shared workbooks": https://docs.microsoft.com/en-us/office/troubleshoot/excel/use-shared-workbook https://support.microsoft.com/en-us/office/what-happened-to-shared-workbooks-150fc205-990a-4763-82f1-6c259303fe05 The preferred mode requires "Microsoft 365 subscription" and latest Office version: https://support.microsoft.com/en-us/office/collaborate-on-excel-workbooks-at-the-same-time-with-co-authoring-7152aa8b-b791-414c-a3bb-3024e46fb104 However -- the key feature is that these are Excel-Excel(-Excel...) operations (and the co-author mode needs M$ subscription and use of OneDrive cloud storage). Most Python libraries are working directly with the Excel format data file, not by running Excel. Caveat: there is a product that appears to use the Excel component API to control Excel itself, not just read/write xls(*) files -- so it might understand the older shared workbook mode, but I'd recommend a detailed study of the API and the sharing operations first: https://www.xlwings.org/ https://docs.xlwings.org/en/stable/ """ xlwings (Open Source) is a BSD-licensed Python library that makes it easy to call Python from Excel and vice versa: * Scripting: Automate/interact with Excel from Python using a syntax close to VBA. * Macros: Replace VBA macros with clean and powerful Python code. * UDFs: Write User Defined Functions (UDFs) in Python (Windows only). """ If running under Windows, similar capability should be possible using the win32py (or whatever the current name is) extension... Or with more difficulty, ctypes! -- Wulfraed Dennis Lee Bieber AF6VN wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/ -- https://mail.python.org/mailman/listinfo/python-list
