djbarnes / django-dump-die Goto Github PK

Can be toggle-able via a setting, but probably default to on.

Would be useful for instances where multiple different values are dumped to output.

Can be as simple as outputting the filename (full path or just filename?) and line num directly before current value output.

Add option to automatically follow Django relations and query for them.

This would require more queries and might result in more processing than the user wants. Might need to add a couple of settings. One for whether to follow and one for how deep of recursion it should do when following relations.

Currently RelatedManagers (and managers in general) are seen as a callable and so they are output as a function and not as a means to get more related objects.

The testing can be done with something like:

from django.db.models import Manager

for attr, value in members:
    if isinstance(value, Manager):
        value = value.all()

Left is how it looks in 3.11. Right is how it looked in prior Python versions.

Right now deepcopy will do just that. Deep copy the object. Thus giving it a new memory address and in turn a new unique. This means that any subsequent dumps of the same object either with or without deepcopy will result in a new unique. Which will prevent the highlighting to know that you are looking at the same object.

It should be possible to keep track of the original unique for the object before deep copying and then make the deep copied one have the original unique so that the unique is intact. This would ensure that regardless of whether deep copy is used or not, output stays consistent.

Move each type of object to process into a separate function.

EX: Skip, Simple, Index Iterable, Full Object.

Then the decision for what to do in the template tag would be more like:

if skip:
    pass
elif simple:
  do_simple()
elif index work:
  do_index
elif full_object:
  do_full object

Outputting a PosixPath objects seems to create a nesting level for each directory involved in the path. It seems to recursively call itself for each such directory path instance. Can almost certainly be improved to be more beneficial output.

Seems very similar to the original output of DateTime objects, and thus this might also be a good usecase for the "Intermediate" type.

Improve the same object highlighting so that it is constrained to a single dump rather than page wide.

Probably need to add some sort of unique identifier to each dumped object's classes and or ids and update the JS to use that identifier to keep things separate. May even be able to use the for loop counter for the main for loop as the identifier as it will be unique for each dumped object.

On the quickstart page (and possibly in other places too), the documentation currently states:

By having the middleware installed, you can run dump() and/or dd() anywhere you want, and it will run the dump logic.

This heavily implies dd/dump will run everywhere, including places that wouldn't make sense, such as non-request-serving bits of logic. Eg: A custom manage.py command would be an obvious example.

Current behavior is that dd/dump can only run in logic that is intercepted by Django's middleware.

However, technically, the dd/dump functions can be imported in any file via from django_dump_die.middleware import dd or dump. Doing such and trying to use those functions from any logic that is not intercepted by middleware will result in strange/unhelpful console output. Because obviously the package can't magically make a request from logic that isn't serving requests to begin with.

At the very least, this should probably be mentioned in the documentation, so it's clear how it functions.

There may also be some (minimal) value from moving the dd/dump imports up (so the import would read from django_dump_die import dd or dump), and then allowing very basic output to console for the currently provided value. Maybe with a warning along the lines of "Django-Dump-Die is meant to be used with web requests. Using this in logic that does not serve a request will result in significantly less detailed output."

It makes sense, since this is meant to be a Django-based package.
See https://docs.djangoproject.com/en/dev/ref/models/fields/#model-field-types for full list.

For each type, we probably want to ensure it outputs correctly as both the root object, and when the direct first-child as part of a dictionary/list object.

See also: https://docs.python.org/3/library/stdtypes.html
For list of built-in python types. It looks like we handle a majority of these by now, but it doesn't hurt to double-check.

Update sphinx docs to match README.

Currently there is no differentiation between static and normal methods.

Not sure how easy this would be to implement (does Python call stack retain if a function is static?), but could be useful information.

Needs verification on other machines and/or in additional projects.

Confirmed when trying to dd a ModelForm that is trying to process the FileField. Happened when FileField attribute was empty.

Suspect that it also happens when trying to dd the corresponding model instance itself, but unconfirmed as of submitting this issue.

This has come up specifically with date/time values, where some functions are very commonly run, to the point that they might as well be an attribute.

For computational cost, we almost certainly do not want to do this for all functions, (as the user can technically just dd on those specific functions anyways). We only want this for very specific functions that are considered common/essential enough to be worth it.

In such cases, we probably want these values to explicitly be stated as coming from a function return (somehow. Current desired output is unknown without testing).

Trying to dd a function works.
Trying to dd a function AND actively call the function in the same line appears to raise an error.

Appears to (maybe?) be an issue trying to parse "obj" (aka function) name.

Gives "EOF in multi-line statement" tokenize.TokenError.
Occurs in django_dump_die/utils.py, process_object_name(), line 119.

Add template tags to be able to dump objects from a template.

Might technically be able to be done right now via the dd_object template tag, but probably ought to have separate dd and dump tags that could be used. That way a user can use dd and dump in both the View and a Template.

Obviously dumping in a template would require loading the template tags. So, not as easy as in a view. Unless there is a way to make some tags "auto-loaded". Which might be worth it if there is.

Seems to be related to call-stack examination.

Currently seems to (generally) output correctly for module-level functions, but breaks with class-level.

Before closing issue, should also examine functions in nested classes, as well as outputting a default value in event of future call-stack examination issues.

Add automated tests to verify functionality
This should include:

• Test a single function.
• Test all simple types.
• Test all built-in data structures.
• Test Simple and Complex classes.
• Test Django simple and complex queries. Might want to use the users table as it is baked into Django.
  • Simple query can be a list of objects / a single object.
  • Complex should include relationships that prefetch data.
  • Probably ought to do values and values_list as well.

When dumping a dictionary that has more keys than the Max Iteration Setting, the values for the keys past the max iter count won't be expandable. It is as if the max iterations setting is also being applied to how many dictionary keys are output.

EX:

DJANGO_DD_MAX_ITERABLE_LENGTH = 1

sample_multilevel_dict = {
    'initial': {
        'first': 'A',
        'second': 12,
        'third': True,
    },
    'secondary': {
        'fourth': 'B',
        'fifth': 24,
        'sixth': False,
    },
}

Using the above as an example, 'initial' will be expandable, but 'secondary' will not.
Both should still be expandable. The max iter length setting should only affect the number of list entries that are output. Not dict keys / values.

Ctrl+Click on the first root element will work as expected, and fully expand all levels of children within.

Ctrl+Click on any further root elements (before closing the first) will minimize all levels of the first root element, and then only open the first level of the newly clicked element.

This "incorrect" behavior seems to persist until all root elements are closed once more.

Ref #11

If/when we implement associated issue, we probably want a user-definable setting to allow stating additional functions to automatically output return values of.

Setting can be something along the lines of:

setting_name = {
    ....
    <type>: <function_name>,
    ....
}

Both types output non-user-friendly gibberish. This could/should be improved.

Add the ability to dump a function as the root thing to dump.

Currently dumps nothing which is not useful.

Definitely makes sense for numerical types, to explicitly indicate if type is float/decimal/maybe-int.

Not sure if it's needed for other "simple types", such as None/str/bool, but may make sense to output these too, just for consistency.

OrderedDict is currently not handled, outputs "No Attributes".