Re: ipdb throws AttributeError in autoreload.py with 2.2.2

2019-06-23 Thread Jason Johns
Wow, that was quick! Thank you!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6b7125aa-404e-4678-8c19-578533cb52fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


ipdb throws AttributeError in autoreload.py with 2.2.2

2019-06-23 Thread Jason Johns
Hello,

About two weeks ago, work updated the base docker image to use django 2.2.2 
and I noticed an issue right off the bat with using ipdb 0.12 and ipython 
7.5.0 (which are also defaults for the docker image).  I really didn't have 
the time to dig more, and got along well enough with pdb in the meantime.  
This weekend, I had some free time to poke around, and these are my 
findings:


In a DRF serializer helper method, I import ipdb and set a breakpoint.  The 
API call executes and stops here.  After anywhere from 1 to 3 seconds pause 
at the breakpoint, I then see the following output from ipdb> and the 
runserver process exits.
> /orm/service/api/serializers/helpers/facet_generator.py(62)__make_facet()
 61 import ipdb; ipdb.set_trace()
---> 62 log.info(f'Facet field: {facet_field}')
 63 log.info(f'Facet values: {facet_values}')

ipdb> Traceback (most recent call last):
  File "/orm/manage.py", line 15, in 
execute_from_command_line(sys.argv)
  File 
"/usr/local/lib/python3.7/site-packages/django/core/management/__init__.py", 
line 381, in execute_from_command_line
utility.execute()
  File 
"/usr/local/lib/python3.7/site-packages/django/core/management/__init__.py", 
line 375, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
  File 
"/usr/local/lib/python3.7/site-packages/django/core/management/base.py", 
line 323, in run_from_argv
self.execute(*args, **cmd_options)
  File 
"/usr/local/lib/python3.7/site-packages/django/core/management/commands/runserver.py",
 
line 60, in execute
super().execute(*args, **options)
  File 
"/usr/local/lib/python3.7/site-packages/django/core/management/base.py", 
line 364, in execute
output = self.handle(*args, **options)
  File 
"/usr/local/lib/python3.7/site-packages/django/core/management/commands/runserver.py",
 
line 95, in handle
self.run(**options)
  File 
"/usr/local/lib/python3.7/site-packages/django/core/management/commands/runserver.py",
 
line 102, in run
autoreload.run_with_reloader(self.inner_run, **options)
  File "/usr/local/lib/python3.7/site-packages/django/utils/autoreload.py", 
line 585, in run_with_reloader
start_django(reloader, main_func, *args, **kwargs)
  File "/usr/local/lib/python3.7/site-packages/django/utils/autoreload.py", 
line 570, in start_django
reloader.run(django_main_thread)
  File "/usr/local/lib/python3.7/site-packages/django/utils/autoreload.py", 
line 288, in run
self.run_loop()
  File "/usr/local/lib/python3.7/site-packages/django/utils/autoreload.py", 
line 294, in run_loop
next(ticker)
  File "/usr/local/lib/python3.7/site-packages/django/utils/autoreload.py", 
line 334, in tick
for filepath, mtime in self.snapshot_files():
  File "/usr/local/lib/python3.7/site-packages/django/utils/autoreload.py", 
line 350, in snapshot_files
for file in self.watched_files():
  File "/usr/local/lib/python3.7/site-packages/django/utils/autoreload.py", 
line 249, in watched_files
yield from iter_all_python_module_files()
  File "/usr/local/lib/python3.7/site-packages/django/utils/autoreload.py", 
line 103, in iter_all_python_module_files
return iter_modules_and_files(modules, frozenset(_error_files))
  File "/usr/local/lib/python3.7/site-packages/django/utils/autoreload.py", 
line 120, in iter_modules_and_files
sys_file_paths.append(module.__file__)
AttributeError: module '__main__' has no attribute '__file__'

If you suspect this is an IPython bug, please report it at:
https://github.com/ipython/ipython/issues
or send an email to the mailing list at ipython-...@python.org

You can print a more detailed traceback right now with "%tb", or use 
"%debug"
to interactively debug it.

Extra-detailed tracebacks for bug-reporting purposes can be enabled via:
%config Application.verbose_crash=True

Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/IPython/core/history.py", 
line 780, in writeout_cache
self._writeout_input_cache(conn)
  File "/usr/local/lib/python3.7/site-packages/IPython/core/history.py", 
line 764, in _writeout_input_cache
(self.session_number,)+line)
sqlite3.ProgrammingError: SQLite objects created in a thread can only be 
used in that same thread. The object was created in thread id 
139743563077376 and this is thread id 139743865329408.



To be sure it wasn't just the project's fault, I checked out another team's 
project and got the same error.  This seems to be isolated to just ipdb.  
Using pdb does not show the same errors

Then, I pulled the latest from django github and confirmed that it is 
probably related to the changes in iter_modules_and_files 

 between 
2.2.1 and 2.2.2.  Looking at ipdb 
's package structure, I 
think the problem is the usage of __main__.py, because it apparently does 
not 

Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-04 Thread Jason Johns
Tom Christie wrote this about what DRF brings to the table over plain Django:

Django REST framework isn't required, but it helps you get a lot of things 
right that will be time consuming and error prone if you're working from core 
Django.
 • Serializers
The Django serializers are not really suitable for anything other than dumping 
and loading fixture data - they don't allow you to customize the representation 
in any substantial way.
Using Django Forms for validation isn't suitable either as they're intended for 
HTML only validation and can't eg handle nested validation.
REST frameworks serializers are designed for API usage and cover both JSON or 
form validation, as well as being able to represent as either HTML Forms or 
formats such as JSON. They also give you lots of scope for handling the 
representation of relationships, such as using hyperlinked relations.
 • Authentication and permissions
REST framework's authentication will gracefully handle both session based and 
token based schemes at the same time, and get the CSRF behavior right. You'll 
find that really awkward to do if using plain Django. It also helps ensure 
you're issuing failure responses that are suitable for API clients (eg get 401 
vs 403 responses right)
The auth, permissions and throttling are also more flexible because they're 
defined at a view level, rather than as middleware or a view decorator. This 
makes it easier to eg combine multiple schemes, or to apply different schemes 
to different parts of your application.
 • Views
Django's generic class based views are suitable to HTML applications. REST 
framework's generic class based views are suitable for API services. Typicallly 
API views have slightly different behavior by convention. Eg create in an HTML 
application might typically redirect the user to the created item, whereas an 
API will respond with a 201 CREATED response.
There's stacks of other functionality and behavior that makes using Django REST 
framework simpler, quicker and likely more correct than if you start with plain 
Django. But those are some of the obvious differences to get started with.

https://reddit.com/r/django/comments/3h9oj8/_/cu5pzu9/?context=1

Seems pretty concise and self explanatory to me. This could easily be adapted 
to be in the docs.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/af24d69f-1d16-40db-9558-11745fce2399%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: revisiting the Python version support policy

2019-01-21 Thread Jason Johns
In addition, with tools like https://github.com/pyenv/pyenv available that make 
changing the currently applicable python version in any given shell extremely 
easy, I feel pinning support to a specific operating system version, however 
stable, is not the optimal approach 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/211103b2-ecb4-4e3e-bf84-85cd049b47ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: A faster paginator for django

2018-12-05 Thread Jason Johns
https://www.citusdata.com/blog/2016/03/30/five-ways-to-paginate/ has some 
interesting alternatives.  I believe Django uses the first one. But the 
others have some tradeoffs that might not apply to all the dbs that django 
supports.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b649819f-80c3-4b12-af07-0914c679287a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Widening participation (Thoughts from DjangoCon)

2018-11-22 Thread Jason Johns
This is prompted by James Bennet's article yesterday 
 which prompted a 
discussion with a coworker of mine.

I've been using django for a while now, am a mid-level at a company that 
uses django/DRF heavily, and am a regular lurker here because its a great 
way to keep up with the happenings of the project.  That said, this is from 
an outsiders perspective:


   1. The documentation of the framework is top notch, but the sections on 
   contributing and getting up to speed with the framework, how to run it 
   while developing on it, etc are sparse.  The codebase is fairly 
   intimidating when you read a ticket and then try to dig in.  Fortunately, 
   all breakage from my experimentation is private and not public :-).  I feel 
   having a much more thorough documentation/examples of ramping up and 
   getting started would do a great job in reducing some of that intimidation 
   factor.
   2. The fellows, Tim and Carlton, do a great job here in triaging tickets 
   and handling the day to day work of the project.  But I feel the bug 
   tracker is being a significant hindrance to contributors and possible 
   contributors, and when combined with a lack of intuitive methods to find 
   easy picking tickets makes it more difficult to get going from scratch.  I 
   imagine this is something that has been discussed before.
   3. I like the idea James proposed about mergers and releasers.  I would 
   also suggest that mergers be people who have significant experience in 
   specific parts of Django and handle merging of those tickets.  This is 
   similar to how the Linux kernel project is set up, with maintainers 
   responsible for specific segments of the code tree.  It would also be great 
   if these mergers had technical team-lead like skills that can be used to 
   shepherd both new and knowledgeable contributors onward and upward with 
   tickets, knowledge and support.

I personally am going to make more of an effort to get more involved here, 
but I think these three points above would help lower the mental resistance 
of someone that wants to enter the project.  I have to wonder, however, how 
well situated the experienced people here are for spending time getting new 
contributors up to speed.  Onboarding a new developer is a major time 
allocation at companies, much less open source projects that are being 
worked on in ocassional company time/spare time across the world.  What's 
the capacity available, and who is available for what kind of questions?  

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6a80dbf4-dcc5-40dc-bca8-11cdcc6e7ab8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Django and Cython

2018-08-03 Thread Jason Johns
Not at all, just that Cython itself is probably not the approach to take.  
Andrew Godwin recently posted a proposal for a Django ASGI roadmap 
 and 
there's a good amount of work to be done there.

Benchmarks have their place.  But if they're not matching real world 
problems, then I don't see much use of them other than stroking egos of 
their developers.  And my personal experience says that most of the 
problems with Django's slowness have most of the bottlenecks with db 
connections, networking latency and other things outside of Python.  And 
those problems inside Python might not be the best things to leverage 
Cython for.

I get the issue of wanting to show up to your peers with node, but 
personally, I just don't find it worth it.  It has its use cases, but more 
and more I see it being squashed into a use case its really not suited for 
simply because the creator or team are very one-dimensional as far as 
languages..  Use the right tool for the job, and just ignore the fanbois.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3a82c5de-b3d0-449a-8e6b-2f008fd9c803%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Django and Cython

2018-08-02 Thread Jason Johns
There was a discussion a while back about this 
https://groups.google.com/forum/#!searchin/django-developers/cython/django-developers/Fi4U602GxHA/mE50LOPkBgAJ

tl;dr not sure what benefits Django would get from it, since the 
bottlenecks you experience are most likely non-Django/Python parts of your 
project, such as networking latency, db queries, connection initiation, 
etc.  In addition, pypy is an alternative interpreter that you can drop in 
for up to 3.5.x Python versions.

On Wednesday, August 1, 2018 at 5:21:38 PM UTC-4, Daniel Anechitoaie wrote:
>
> I'm looking at frameworks like https://vibora.io/ that make use of Cython 
> to greatly improve the performance and I'm just wondering if something like 
> this would work with Django?
> Was there any discussion (taken into consideration) about using Cython to 
> boost the performance of certain aspects of the framework?
> Would it help make it faster?
>
> I really love Python and Django for me is the best web framework out 
> there, but you have to notice how fast other frameworks from other 
> programming languages are.
> Would using Cython help boost the performance?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7173fb49-48d3-48c0-a711-0671af91d297%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.