Re: [Feature Request] Having an middleware to be able to force authentication on views by default

[Fabio Caritas Barrionuevo da Luz]

> I'm surprised nobody has mentioned django-stronghold in this discussion 
which does exactly what you're looking for. 

Same here. django-stronghold has been working well in my projects for me 
for years. 

https://github.com/mgrouchy/django-stronghold 



Em quinta-feira, 19 de março de 2020 07:41:35 UTC-3, Matt Magin escreveu:
>
> Hi all,
>
> I'm surprised nobody has mentioned django-stronghold in this discussion 
> which does exactly what you're looking for. 
>
> It's implemented as a middleware, with two settings for exclusions -- A 
> list of named url's or a list of regex's to match url's against. 
>
> This works well, and managing the exclusions through settings is not a big 
> deal. Having said that, I do like the idea of putting it inside the Auth 
> middleware as well.
>
> +1 from me to put this into core functionality, I include 
> django-stronghold in basically all my projects already.
>
> Cheers,
> Matt
>
> On Thu, Mar 19, 2020 at 7:19 PM Mehmet Ince  > wrote:
>
>> Hi Alasdair,
>>
>> On 16 Mar 2020, at 12:59, Alasdair Nicol > > wrote:
>>
>> Hi,
>>
>> Creating Django settings is often discouraged, so perhaps it would be 
>> better to create a subclass of AuthenticationMiddleware instead of adding a 
>> setting. Then users would update MIDDLEWARE to enable the new functionality.
>>
>>
>> I see, that supports my initial idea. I was planning to have new 
>> middleware but creating a subclass of AuthenticationMiddleware with a 
>> process_view function is way better. People who want to enabled that 
>> feature can directly replace AuthenticationMiddleware with our new 
>> middleware.
>>
>> To be honest, I’m kind a confused about how to proceed. Should I continue 
>> with settings to control it or subclass of Auth middleware ? 
>>
>> I really want to contribute to the Django thus I’m willing to send PR for 
>> that feature, because it looks like newbie friendly in terms of 
>> implementation, but I think I need a kind of confirmation from core devs.
>>
>>
>> Cheers,
>> Alasdair
>>
>> On Sunday, 15 March 2020 17:46:48 UTC, Mehmet Ince wrote:
>>>
>>> Hi Adam,
>>>
>>> Thanks for your comments. I was thinking to implemented this as a 
>>> separated middleware but, as you said, AuthenticationMiddleware is much 
>>> better place to do it.
>>>
>>> I already started to implementing this in AuthenticationMiddleware. I 
>>> would like to send a PR if it’s okay to everyone ?
>>>
>>> I’m not sure it’s okay to discuss this in mailing list but I need a help 
>>> about naming convention for following variables/class/function:
>>>
>>> - Variable name to control this in settings.py. ( FORCE_LOGIN_REQUIRED 
>>> maybe ? )
>>> - Mixing name for CBV and decorator name FBV  ( AnonymousUserMixin and 
>>> @anonymous_user ? )
>>>
>>> Thanks,
>>> M.
>>>
>>> On 15 Mar 2020, at 17:13, Adam Johnson  wrote:
>>>
>>> Hi Mehmet,
>>>
>>> I like your move to fail-closed here. I've certainly seen missing auth 
>>> decorators as a recurring issue in my career, and I do think as an OWASP 
>>> top ten we should try tackle it better in the framework.
>>>
>>> Your implementation is very few lines of code. It could be made more 
>>> robust, using the attribute approach that the CSRF middleware uses: 
>>> https://github.com/django/django/blob/7075d27b0c75f1431f29497f4353cd742906b357/django/middleware/csrf.py#L209
>>>  
>>> . And it could easily be added to django.contrib.auth, and the default 
>>> project template. AuthenticationMiddleware doesn't in fact have a 
>>> process_view method at current, so we could even add it there with a 
>>> setting to control it.
>>>
>>> I doubt many would be against it as an optional extra.
>>>
>>> Thanks,
>>>
>>> Adam
>>>
>>> On Sun, 15 Mar 2020 at 06:36, Václav Řehák  wrote:
>>>
 Hi Tobias,

 Dne sobota 14. března 2020 9:44:16 UTC+1 Tobias Bengfort napsal(a):
>
>
> Another option could be to add system checks for this: Instead of 
> silently "fixing" missing code it would inform developers about 
> missing 
> decorators/mixins. (If I have time I might try to come up with a 
> prototype of this.)


 my thinking about this is exactly the same as yours. I have seen issues 
 with developers forgetting to add LoginRequiredMixin almost on all 
 projects 
 I worked on and I think all of this issues would have been prevented if 
 the 
 developers were force to explicitly specify the desired authentication 
 requirements for each view (probably using the checks system).

 In my current project we added a testcase to go through all urls in 
 urlconf and compare then to whitelist of public urls. But it is ugly as it 
 hardcodes urls as strings (similar to the django-utils repo) defeating the 
 flexibility of url patterns.

 -- 
 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 sto

Re: Adding Quantum Encryption to Django Project

[Fabio Caritas Barrionuevo da Luz]

What do you mean by Quantum Encryption/Quantum hashing?

It would be nice to explain what it is and / or send some links to more 
information.

That said, I think for anything to be integrated into the core of django, 
it should first, as far as possible, prove its concept as an external 
django app and prove to be useful for a large number of projects.


On Wednesday, May 8, 2019 at 8:59:20 AM UTC-3, Harold Heard wrote:
>
> Greetings Django Development Community,
>
>  
>
> I am interested to know if the Django community is open and/or considering 
> adding quantum hashing to the project.  
>
>  
>
> I have a project need for this functionality and would like to capture the 
> vision and direction in this area.
>
>  
>
> I’m glad to participate to the depth required.
>
>  
>
> Thank you,
>
> *Harold Heard*
>
> Email: *m...@haroldheard.com *
>
> *https://linkedin.com/in/haroldheard 
> *
>

-- 
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/7393d263-a6d8-45de-a8d4-98688eab2c5e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: translate django documentation

[Fabio Caritas Barrionuevo da Luz]

Hello Adson, Brazilian community has a Telegram Group to talk about 
translation (of Python and related technologies) and help new translators:

please run this code to get the link to the Telegram group:


print(''.join([chr(i - 105) for i in [209, 221, 221, 217, 220, 163, 152, 
152, 221, 151, 214, 206, 152, 217, 226, 203, 219, 200, 210, 154, 161, 
215]]))


ps: I'm avoiding to share the link directly, because we had to abandon the 
first group we had, because too many pornographic bots discovered us and 
started to make the group a hell, and complicated to manage.



Em segunda-feira, 29 de outubro de 2018 23:54:42 UTC-3, adson@gmail.com 
escreveu:
>
> Hi,
>
> I'm starting to work with Django now and would like to contribute to the 
> community, but I have not seen any related contribution topics on 
> translating documentation to other languages.
>
> Is there a thread or ticket where I can contribute to that? I would really 
> like to start contributing this way because I would gain maturity with the 
> framework and learn by translating into my native language (pt-br)
>
> Best regards,
>

-- 
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/2dbd5539-b159-4460-a5db-60424daf3f7d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Set formfield.initial when created using modelformset_factory

[Fabio Caritas Barrionuevo da Luz]

try https://django-autocomplete-light.readthedocs.io/en/master/


Em quarta-feira, 23 de maio de 2018 15:58:20 UTC-3, Brock Hallenbeck 
escreveu:
>
> Thanks Collin, that does help.
>
> I guess I am going to have to take a fundamentally different approach to 
> accomplish what I want.
>
> I have attempted to make an AJAX solution for foreign key dropdowns with 
> >1000 options by creating a subclass of ModelChoiceField. 
>
> By also subclassing its iterator I was able to prevent the large queryset 
> from being evaluated/rendered so it loads quickly, and because I didn't use 
> limit_choices_to, validation still works. I then use a textbox to catch 
> search terms and fire off the AJAX call will populate the dropdown with the 
> matching data.
>
> However if there is an initial value supplied, this obviously won't be 
> honored as the initial value is not present in the (empty) dropdown.
>
> The dream was to use formfield.initial to create and select the single 
> requested option, however it seems that is a no go.
>
> Perhaps I will have to cave in and use one of the googleable ajax-select 
> solutions.
>
> On Wednesday, May 23, 2018 at 2:38:40 PM UTC-4, Collin Anderson wrote:
>>
>> Hi Brock,
>>
>> Yes, that's the intended behavior, and you can see the same behavior on a 
>> regular form, without using formsets, which might make it a little more 
>> clear what's going on:
>>
>> class MyForm(forms.Form):
>> name = forms.CharField()
>>
>> form = MyForm(initial={'name': 'test'})
>> form.initial  #yields {'name':'test'}
>> form['name'].initial #yields 'test'
>> form.fields['name'].initial #yields None
>>
>> The field itself is shared between all instances of MyForm, so passing in 
>> initial data to one instance of MyForm shouldn't modify the field. 
>> Instead, the BoundField is used to hold the data for a particular form, and 
>> as you mention, as the initial value on the boundfield has that value you 
>> expect.
>>
>> Hope this helps,
>> Collin
>>  
>>
>> On Wed, May 23, 2018 at 2:04 PM, Brock Hallenbeck  
>> wrote:
>>
>>> When creating a formset using modelformset_factory and passing in a list 
>>> of dictionaries to use as initial values, those values can be retrieved 
>>> from the relevant form, and the relevant boundfield on that form.
>>> However the formfield class itself has no knowledge of that initial data.
>>>
>>> Is this intended behavior? I feel like I should be able to catch that 
>>> initial value in my formfield subclasses.
>>>
>>> Here is a dpaste illustrating what I am talking about:
>>>
>>> https://dpaste.de/As6Z
>>>
>>> -- 
>>> 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-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@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/1d84a32c-d70a-4d42-8b94-ca19f27ede0e%40googlegroups.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

-- 
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/27376ad8-12c0-49e4-af47-97be82f40328%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improving MSSQL and Azure SQL support on Django

[Fabio Caritas Barrionuevo da Luz]

is there any update about the progress of this?

-- 
Fábio C. Barrionuevo da Luz
Palmas - Tocantins - Brasil - América do Sul



Em terça-feira, 13 de outubro de 2015 18:12:55 UTC-3, Tim Graham escreveu:
>
> If anyone is interested in listening in on the meetings with Microsoft 
> engineers (Wednesday and Thursday 9am-5pm Pacific), let me know and I'll 
> send you the Skype link.
>
> On Friday, October 2, 2015 at 11:53:17 AM UTC-7, Meet Bhagdev wrote:
>>
>>
>>
>> On Thursday, October 1, 2015 at 12:32:25 PM UTC-7, Tim Graham wrote:
>>>
>>> Hi Meet,
>>>
>>> I was wondering
>>>
>>> 1. If you have any progress updates since your last message?
>>>
>> 
>>
>> * Yes, engineers on my team I are currently ramping up on the three 
>> Django-SQL Server adapters*
>>
>>
>>- *  Django-pymssql*
>>- * Django-pyodbc-azure*
>>- 
>> * Django-mssql *
>>
>> * The goal is to have a thorough understanding of what’s good and 
>> what’s bad with these adapters before the event. *
>>
>>>
>>> 2. If you have any further details on the schedule for the time in 
>>> Seattle in a week and a half? (including video conference details for those 
>>> unable to attend in person)
>>>
>>
>>- *We will have a video conference link for Day 2 and Day 3. 
>>Participants interested can join the conference stream from their 
>> browser. 
>>The conference room mics are only capable to a certain extent. Thus the 
>>quality might be a little poor. *
>>
>>
>>- *We are finalizing the detailed schedule this week and will post it 
>>on this thread by next Friday.  *
>>
>>
>> 3. If myself or the other attendees should do anything to prepare for the 
>>> meetings?
>>>
>>> *Here are some things that you should prepare before coming to 
>> Seattle.*
>>
>> *-*
>>
>>
>>- 
>> * Have a clear understanding of the things that you need from 
>>Microsoft to improve the SQL Server support on Django. We have resources 
>> to 
>>do the heavy lifting but need guidance. *
>>- * Share with us the issues we can help fix (on the Django side 
>>and on the Django-ORM(database) side). *
>>
>>
>> Thanks!
>>>
>>> On Thursday, September 17, 2015 at 3:38:09 PM UTC-4, Tim Allen wrote:

 Hey team, as promised, here are the simple tests I put together to 
 benchmark pyodbc vs pymssql. Be kind, this was Python I wrote a long time 
 ago!

 https://github.com/FlipperPA/pyodbc-pymssql-tests

 I've included example output on the README. Very basic, but useful.

 On Wednesday, September 16, 2015 at 11:27:59 AM UTC-4, Tim Allen wrote:
>
> Thanks for all of your efforts, Aymeric, I've been following your 
> project since its inception - I'm FlipperPA on GitHub.
>
> On Sunday, September 13, 2015 at 4:59:34 AM UTC-4, Aymeric Augustin 
> wrote:
>>
>> Did you mean “pyodbc outperforms pymssql”? Or did you go with pyodbc 
>> despite lower performance? (Or did I misread that?)
>>
>
> We went with pyodbc, despite lower performance. I've been meaning to 
> put the simple tests up on GitHub - making a note to do that this week.
>
> At the time we were looking at options, we couldn't find a stable 
> Django option for pymssql. I should have been more clear about the time 
> frame in which we were testing as well; this was right around the time 
> that 
> you first started django-pymssql. 
>
>>
>>- django-pymssql is basically django-mssql on Linux. We could 
>>debate whether django-pyodbc-azure is more stable than django-mssql. 
>>There’ve been a bunch of forks over the years.
>>
>>
>> I’m not going to argue it further because I would inevitably sound 
>> like I’m tooting my own horn which isn’t my intent. I will just say that 
>> the picture isn’t all that clear.
>>
>
> There is definitely much more to consider now, than when we were first 
> assessing options. I will say I've been impressed with 
> django-pyodbc-azure 
> staying up to date with Django's releases.
>
> From the perspective of someone who works on Django’s internals, I 
>> believe django-pyodbc-azure could use a review of how the Django 
>> database 
>> backend API is implemented.
>>
>> For example, looking at the new transaction APIs I introduced in 1.6, 
>> I see that it commits or rolls back implicitly in _set_autocommit. 
>> At best that’s weird and useless, at worst a data corruption bug.
>>
>> Nothing that couldn’t be fixed, but just because the code works 
>> doesn’t means it handles edge cases well. django-mssql probably fares a 
>> bit 
>> better since its author cooperated with and eventually joined the core 
>> team.
>>
>> Thanks to the abstraction provided by the Python DB-API, it should be 
>> quite easy to port code implementing Django’s database back

Re: delegating our static file serving

[Fabio Caritas Barrionuevo da Luz]

A question: are there any plans to also improve MEDIA files (user uploaded 
files) in any foreseeable future?

Perhaps this is outside the scope of Django, but I believe Django could 
provide by default, any option to get a little more control over who can 
and can not access the MEDIA files.

Most Django deployment tutorials with Nginx and Apache that saw out there 
do not say anything on the issue of data security.

I believe it is a common use case, that not every file sent by a User 
should be available and accessible to anyone on the web.

Out there, I found these two implementations:

https://github.com/benoitbryon/django-downloadview

https://github.com/johnsensible/django-sendfile


-- 
Fábio C. Barrionuevo da Luz
Palmas - Tocantins - Brasil - América do Sul

http://pythonclub.com.br/



Em quinta-feira, 31 de dezembro de 2015 19:44:01 UTC-3, Collin Anderson 
escreveu:
>
> I'm still +1 to django providing a good file solution, whether it be 
> whitenoise, dj-static, or whatever.
>
> Here's all I came up with the last time I looked into this. It basically 
> involves passing insecure=True into our current code and sending cache 
> headers. (I feel like the insecure flag could get renamed to inefficient or 
> something like that.) I feel like the code we have really isn't all that 
> bad. Using something like whitenoise or dj-static allows you to bypass 
> middleware, which can really improve performance (if you have inefficient 
> middleware installed), but on the other hand, some people may want to use 
> the currently logged in user to determine whether or not to serve the file.
>
> Collin
>
> import re
>
> from django.conf import settings
> from django.conf.urls import url
> from django.contrib.staticfiles.views import serve as static_serve
> from django.core.exceptions import ImproperlyConfigured
> from django.views.decorators.cache import cache_control
> from django.views.static import serve
>
>
> def static(prefix, view=serve, **kwargs):
> if not prefix:
> raise ImproperlyConfigured("Empty static prefix not permitted")
> if '://' in prefix:
> return []
> if not settings.DEBUG:
> view = cache_control(max_age=86400 * 30)(view)
> return [
> url(r'^%s(?P.*)$' % re.escape(prefix.lstrip('/')), view, 
> kwargs=kwargs),
> ]
>
> urlpatterns = static(settings.STATIC_URL, view=static_serve, insecure=True
> )
>
> if settings.MEDIA_URL and settings.MEDIA_ROOT:
> urlpatterns += static(settings.MEDIA_URL, document_root=settings.
> MEDIA_ROOT)
>
>
> On Thursday, December 31, 2015 at 7:42:54 AM UTC-5, Aymeric Augustin wrote:
>>
>> 2015-12-31 12:52 GMT+01:00 Anssi Kääriäinen :
>>
>>> In my opinion one of the most important goals for Django is to make
>>> deploying tiny projects securely and easily a trivial matter. We
>>> aren't there right now.
>>>
>>
>> +1
>>
>> I'm maintaining three such sites (my wife's, my consultancy's and mine). 
>> I'm
>> clearly not going to bother configuring a CDN. I deployed them with 
>> whitenoise
>> — which isn't nearly as well known as it should be. If I hadn't known 
>> about
>> it, I suspect I would have rolled a poor man's solution to serve static 
>> files
>> in Python, because that's the easiest when deploying to a PaaS.
>>
>> Regarding the question of media files raised earlier in this thread, I 
>> think
>> we shouldn't attempt to cache all existing files on start-up because even
>> small sites could easily have tens of thousands e.g. a forum that stores
>> users' avatars. We should look up the file at each query, which will be
>> slightly less efficient, but functional and not subject to scalability 
>> issues.
>>
>> For both static and media files, we care about simplicity and security. It
>> appears that whitenoise gives us great performance for static files as 
>> well,
>> which is good. If we can't have it for media files, it's still fine.
>>
>> -- 
>> Aymeric.
>>
>

-- 
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/6b3b995c-ca28-4a61-a8b6-023314ca8b70%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Config file for startproject.

[Fabio Caritas Barrionuevo da Luz]

for example, check whether this level of customization capabilities of the 
generated project that you need:


pip install tox cookiecutter

cookiecutter https://github.com/ionelmc/cookiecutter-pylibrary.git


The ionelmc cookiecutter-pylibrary project uses the cookiecutter hooks to 
customize post-generated project[1]

that said, the cookiecutter master branch, not yet released, now supports 
choices[2]

[1] 
http://cookiecutter.readthedocs.org/en/latest/advanced_usage.html?highlight=hook#using-pre-post-generate-hooks-0-7-0
[2] https://github.com/audreyr/cookiecutter/issues/441


Em terça-feira, 23 de junho de 2015 08:17:14 UTC-3, Josh Crompton escreveu:
>
> Sounds like you might want to take a look at cookiecutter[0] and/or 
> project templates[1] 
>
> [0] https://github.com/audreyr/cookiecutter 
> [1] 
> https://docs.djangoproject.com/en/dev/ref/django-admin/#startproject-projectname-destination
>  
>
> On Tue, Jun 23, 2015 at 2:26 PM, Hiroki Kiyohara  > wrote: 
> > Thanks, Josh. 
> > 
> > * I thought the config (.djangorc) should be included in project 
> template 
> > it's own. 
> > * bash alias is OK, but it's not easy to share this way with lots of 
> > developers like "Hey, when you start development, please type `alias 
> > mystartproject...` (so long)." 
> > 
> > anyway, I got it. I'll create some aliases or wrapper commands if it's 
> > necessary. 
> > 
> > 
> > On Tue, Jun 23, 2015 at 12:08 PM, Josh Smeaton  > 
> > wrote: 
> >> 
> >> There are a couple of problems with this proposal IMO. 
> >> 
> >> 1) The .djangorc file would need to be somewhere on the file system 
> (like 
> >> ~/.djangorc), because you want it for the startproject command, it 
> can't be 
> >> deployed with startproject 
> >> 2) It doesn't seem to provide that big a benefit 
> >> 3) A simple bash alias can achieve the exact same result 
> >> 
> >> I just don't think this is something that Django needs to take on when 
> >> it's very easy to create your own alias that does exactly what you 
> need. 
> >> 
> >> Regards, 
> >> 
> >> 
> >> On Tuesday, 23 June 2015 12:38:24 UTC+10, Hiroki Kiyohara wrote: 
> >>> 
> >>> Hi all. 
> >>> 
> >>> I propose a new feature `.djangorc`. 
> >>> It should be included in root of project template. 
> >>> You can write down configations for `startproject --template=...` 
> >>> 
> >>> ## Motivation 
> >>> 
> >>> I always use custom project template, but it requires a lot of 
> arguments 
> >>> like... 
> >>> 
> >>> django-admin startproject --template=/path/to/template 
> >>> --extension=py,md,rst,ini,cfg --name=.coveragerc  
> >>> 
> >>> Actually I use this `startproject` feature to create 'repository 
> >>> skeleton' not only django's project directory. 
> >>> 'repository skeleton' contains like README.md, tox.ini, .coveragerc, 
> and 
> >>> django's project direcotry and so on. 
> >>> 
> >>> I know this usage of `startproject` is little tricky. but I think some 
> of 
> >>> django users use like this and 
> >>> want this `.djangorc` feature (not to pass a lot of argument). 
> >>> 
> >>> ## Proposal 
> >>> 
> >>> `.djangorc` will contain some of this. 
> >>> 
> >>> ``` 
> >>> [startproject] 
> >>> extension=py,md,rst,ini,cfg 
> >>> name=.coveragerc 
> >>> ``` 
> >>> 
> >>> and If some project template contains this file, startproject command 
> >>> follow this config on creation process. 
> >>> 
> >>> How do you think about it? 
> >>> It's just my idea and there's no implementation. 
> >>> I want your feedback, thank you. 
> >>> 
> >> -- 
> >> You received this message because you are subscribed to a topic in the 
> >> Google Groups "Django developers (Contributions to Django itself)" 
> group. 
> >> To unsubscribe from this topic, visit 
> >> 
> https://groups.google.com/d/topic/django-developers/mOMTohdfVOI/unsubscribe. 
>
> >> To unsubscribe from this group and all its topics, send an email to 
> >> django-develop...@googlegroups.com . 
> >> To post to this group, send email to django-d...@googlegroups.com 
> . 
> >> Visit this group at http://groups.google.com/group/django-developers. 
> >> To view this discussion on the web visit 
> >> 
> https://groups.google.com/d/msgid/django-developers/c4da9a61-fc06-4992-acff-12db064c91de%40googlegroups.com.
>  
>
> >> 
> >> For more options, visit https://groups.google.com/d/optout. 
> > 
> > 
> > -- 
> > 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-develop...@googlegroups.com . 
> > To post to this group, send email to django-d...@googlegroups.com 
> . 
> > Visit this group at http://groups.google.com/group/django-developers. 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/django-developers/CAPYpbLUWr2sPtyS8V7KwrgbyBnxs-Mko%2B_3dendHY-y-a3eEhQ%40mail.gmail.com.
>  
>
> > 
> > For more options, visit https://gr

Re: Looking for Django mentor to help with an ongoing project.

[Fabio Caritas Barrionuevo da Luz]

Hi,

this mailing list is about the development of django itself, please post to 
django-users  instead.


Em terça-feira, 19 de maio de 2015 12:25:13 UTC-3, SB escreveu:
>
>  Hi, 
> We are a group of students and are putting together a website in Django. 
> Our experience with Django is somewhat limited and we are looking for 
> someone with experience in Django that would be able to review what we did 
> and give us feedback and tips on what the best approach  would be.
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/34b0164c-67d4-4ac0-9db8-68252b7b565f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Database based on country]

[Fabio Caritas Barrionuevo da Luz]

Hello xino12.

This group is for the discussion of the development of Django itself. If 
you want to ask questions about using Django, please post on django-users 
.


--
Fábio C. Barrionuevo da Luz

Em sábado, 7 de março de 2015 16:52:35 UTC-3, xino12 escreveu:
>
> Hi,
>
> is there any possibility that we could select the database to which route 
> a request of a user depending on the geolocalization of the client? Or the 
> user country?
>
> I've check some documentation of the dbrouters, but I am concerned that if 
> a user travels to another country he is going to be routed to the wrong 
> database.
>
> Does anybody have this issue?
>
> -- 
> Gràcies,
>
> Rubén
>  

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ae8a3f2f-eb9f-4e14-87d6-cc4bd985886d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making the test suite run faster

[Fabio Caritas Barrionuevo da Luz]

Parallel is different than concurrent, did you come to look at the package 
"testtools", I think it implements something similar to what you want to do


https://github.com/testing-cabal/testtools/blob/master/testtools/testsuite.py#L38-L198
http://stackoverflow.com/a/17059844/2975300


Em sexta-feira, 6 de fevereiro de 2015 13:06:02 UTC-3, Aymeric Augustin 
escreveu:
>
> Hello,
>
> As the test suite is growing, it’s getting slower. I’ve tried to make it 
> faster by running tests in parallel.
>
> The current state of my experiment is here: 
> https://github.com/django/django/pull/4063
>
> I’m distributing the tests to workers with the multiprocessing module. 
> While the idea is simple, the unittest APIs make its implementation painful.
>
> ** Results **
>
> Without the patch:
>
> Ran 9016 tests in 350.610s
> ./runtests.py  355,86s user 20,48s system 92% cpu 6:48,23 total
>
> With the patch
>
> Ran 9016 tests in 125.778s
> ./runtests.py --parallel  512,31s user 29,92s system 300% cpu 3:00,73 total
>
> Since it takes almost one minute to create databases, parallelization 
> makes the execution of tests go from 6 minutes to 2 minutes.
>
> This isn’t bad, but the x3 speedup is a bit disappointing given that I 
> have 4 physical / 8 logical cores. Perhaps the IPC is expensive.
>
> Does anyone have insights about scaling with multiprocessing?
>
> ** Limitations **
>
> This technique works well with in-memory SQLite databases. Each process 
> gets its own copy of the database in its memory space.
>
> It fails with on-disk SQLite databases. SQLite can’t cope with this level 
> of concurrency. It timeouts while attempting to lock the database.
>
> It fails with PostgreSQL (and, I assume, other databases) because tests 
> collide, for instance when they attempt to load the same fixture.
>
> ** Next steps **
>
> At this point, the patch improves the common use case of running 
> `./runtests.py` locally to check a database-independent change, and little 
> else.
>
> Do you think it would be useful to include it in Django anyway? Do you 
> have concerns about the implementation? Charitably, I’ll say that “it 
> works”…
>
> Releasing it separately as a custom test runner may be more appropriate.
>
> What do you think?
>
> -- 
> Aymeric.
>
>
>  
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/dc81ae00-80a9-466e-9f86-7b93968ea80a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC 2015 project ideas suggestion

[Fabio Caritas Barrionuevo da Luz]

Some ideas. (which still require approval of the core developers):


* Improve database backend base API and related features(including 
introspection feature used by inspectdb), so that it is less complicated to 
add in the future support the specific features of some backends. eg 
multiple database schemas (common used in Oracle and PostgreSQL) and/or 
Oracle synonym tables

* port Django i18n and i10 and related translation features to use 
Babel: http://babel.pocoo.org/ 



Em terça-feira, 27 de janeiro de 2015 14:15:20 UTC-3, Asif Saifuddin 
escreveu:
>
> Hi,
>
> Although probably It's quite very early to ask about GSOC 2015 in January, 
>  I would like to start analyzing to prepare myself for choosing a correct 
> project and submitting a good proposal for that to get selected. I haven't 
> found any GSOC 2015 project ideas pages yet. But got some older idea pages 
>  of year 2013 and 2014. Should I look forward to the ideas that were 
> unimplemented or wait for gsoc 2015 wiki ideas page?
>
> ./auvipy
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cbb457c7-66cb-4370-99de-c9cfcd2a5622%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pull request builder now on Ubuntu 14.04

[Fabio Caritas Barrionuevo da Luz]

Tim Graham,
 I plan to work on the tickets [1][2], how can I replicate the test servers 
in my own infrastructure?

I'm still learning, so do not like to consume resources with my 
implementation attempts.

[1] https://code.djangoproject.com/ticket/6148
[2] https://code.djangoproject.com/ticket/22673


Em segunda-feira, 26 de janeiro de 2015 14:33:11 UTC-3, Tim Graham escreveu:
>
> The pull request builders are now running on Ubuntu 14.04. The master 
> still runs 12.04 and handles builds for versions older than 1.8 as those 
> builds don't pass on 14.04. Also I've reserved three of the slaves for the 
> pull request builder -- this should hopefully cut down on the dreaded "git 
> checkout  where hash was not the commit" errors.
>
> A reminder that the documentation for the CI cluster is on the wiki:
> https://code.djangoproject.com/wiki/Jenkins
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0c449689-2bb9-4305-a6a9-61bf36b3e214%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANNOUNCE] Django 1.8 alpha 1 released

[Fabio Caritas Barrionuevo da Luz]

Em sexta-feira, 16 de janeiro de 2015 20:10:37 UTC-3, Tim Graham escreveu:
>
> We've made the first release on the way to Django's next long-term support 
> release, Django 1.8! With only two and a half months until the scheduled 
> final release, we'll need prompt testing from the community to ensure a 
> timely and stable release. Check out the blog post:
>
>
> https://www.djangoproject.com/weblog/2015/jan/16/django-18-alpha-1-released/
>


Wow, many new things. Very good.

I have not seen in the release-notes that the inspectdb now supports 
inspect "database views" to the backends where it is supported.

This change was made in this commit:

https://github.com/django/django/commit/b8cdc7dcc3fc6897fb2a75f90023f5c67aad327f
 

See the "get_table_list" function in introspection.py file, in each 
database backend

I look forward a day, that Django has support for inspecting "multiple 
database schemas" and work properly with an official api to do this.

https://code.djangoproject.com/ticket/22673
https://code.djangoproject.com/ticket/6148

I was trying to figure out ways to solve this old problem of django.
Also i know that adding support for multiple database schemas is not 
something trivial for Django, because if it was, I'm sure that would be 
already been implemented.

https://gist.github.com/luzfcb/e5f67e9c940e4833b798
http://dba.stackexchange.com/questions/87463/in-oracle-how-to-get-a-list-with-the-names-of-schemas-that-a-user-has-read-perm



-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8e1efdd2-b8d4-4f7d-a498-188f06ff8999%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding hard dependencies to Django's test suite

[Fabio Caritas Barrionuevo da Luz]

python 2.7.9 rc1 include a backported version of python3 ensurepip

see: 

https://hg.python.org/cpython/rev/592a5414fabd
https://docs.python.org/2/library/ensurepip.html

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/173434d5-3313-47b6-bfed-07463c58aa8a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: inspectdb and non "public" schema in postgresql

[Fabio Caritas Barrionuevo da Luz]

Tomek, is exactly that.

Russell, results of my tests inside dbshell:

https://gist.github.com/luzfcb/d85b4012c55471fe3f71

the database that example I used is attached.

inspectdb realy dont work with postgresql schema

I opened the new ticket to handle this: 
https://code.djangoproject.com/ticket/22673

Checked that this is an old problem of Django.

rapid search about this:

https://code.djangoproject.com/ticket/1051
https://code.djangoproject.com/ticket/6148

https://groups.google.com/forum/#!topic/django-users/CifsBczps1M
https://groups.google.com/forum/#!topic/django-users/YJ-4L_gsCrA


Em terça-feira, 20 de maio de 2014 05h55min05s UTC-3, Tomek Paczkowski 
escreveu:
>
> If I understand correctly, your legacy database is not in "public" schema.
> Django offers no support for Postgres schemas, it's left to the 
> developer/ops people to have correct search_path set.
> There are two possible fixes for you: 
> - set Postgres user default search path to contain your schema
> - hook into connection_created signal and set search pach manually[1]
>
> [1]: https://docs.djangoproject.com/en/dev/ref/signals/#connection-created
>
> On Monday, May 19, 2014 11:38:20 PM UTC+2, Fabio Caritas Barrionuevo da 
> Luz wrote:
>>
>> Hello Django core developers.
>> Sorry if this is not the correct place to handle this.
>>
>> I have a legacy database in PostgreSQL, which is still in production.
>> I want to migrate it to Django. 
>> I tried to do the reverse engineering of the database to generate models 
>> classes
>>
>> I set my settings like this:
>>
>> DATABASES = {
>> # this read/write into "public" postgresql schema
>> 'default': {
>> 'ENGINE': 'django.db.backends.postgresql_psycopg2',
>> 'NAME': 'neweposse',
>> 'USER': 'neweposse_user',
>> 'PASSWORD': 'neweposse_user',
>> 'HOST': '127.0.0.1',
>> 'PORT': '5432',  
>> },
>> # legacy database
>> 'eposse': {
>> 'ENGINE': 'django.db.backends.postgresql_psycopg2',
>> 'NAME': 'eposse',
>> 'USER': 'eposse_user',
>> 'PASSWORD': 'eposse_user',
>> 'HOST': '127.0.0.1',
>> 'PORT': '5432',
>> }
>> }
>>
>>
>> in terminal:
>>
>> (django1.7a5)sutransdev@sutransdev:~/webdocpy$ python manage.py inspectdb
>> ...
>> from __future__ import unicode_literals
>>
>> from django.db import models
>>
>> (django1.7a5)sutransdev@sutransdev:~/webdocpy$ python manage.py inspectdb 
>> --database=eposse
>> ...
>> from __future__ import unicode_literals
>>
>> from django.db import models
>>
>>
>>
>> inspectdb not identify the tables in the database and does not generate 
>> the model classes
>>
>>
>> The question is?
>>
>> 1) Am I doing something wrong. Currently there any way he could get 
>> Django to recognize a schema different from the "public" database schema? 
>>
>> 2) This is really a bug, and I need to create a ticket for this? 
>>
>> 3) or Django does not currently support different database schema, but 
>> this feature will be added when Marc Tamlyn add enhanced features to 
>> postgresql, as described here:
>>
>> https://www.kickstarter.com/projects/mjtamlyn/improved-postgresql-support-in-django?
>>
>>
>>
>> Thanks for the hard work to maintain this great framework
>>
>>
>>
>> -- 
>> Fábio C. Barrionuevo da Luz
>> Acadêmico de Sistemas de Informação na Faculdade Católica do Tocantins - 
>> FACTO
>> Palmas - Tocantins - Brasil - América do Sul
>>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/89366504-8f63-4258-b207-e0dd4054d3f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


pulls_non-public_schema.backup
Description: Binary data

Re: error in "makemessages" command on latest django version (1.8dev)

[Fabio Caritas Barrionuevo da Luz]

it was really a bug


apparently solved in
https://github.com/django/django/commit/d1799233f46c39379fe429a4ece128d96b128006

Is it still necessary create a new ticket for this?


Em quarta-feira, 30 de abril de 2014 23h35min59s UTC-3, Fabio Caritas 
Barrionuevo da Luz escreveu:
>
> Hello sorry if this is not the correct place for these questions
> I was testing the latest version of Django[1] directly from Github and am 
> having this problem.
>
> In this link you can see all the steps I did to get this error
>
> https://asciinema.org/a/9213
>
> I try:
>
> python manage.py makemessages
>
> Result in this: 
>
> *optparse.OptionConflictError: option -e/--extension: conflicting option 
> string(s): -e*
>
> That would be a bug or am I doing something wrong
>
>
>
> [1] 
> https://github.com/django/django/tree/8f6dff372b174e772920de6d82bd085f1a74eaf2
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e333bffb-f8e1-4e19-9b9a-cb7bc59e62dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

error in "makemessages" command on latest django version (1.8dev)

[Fabio Caritas Barrionuevo da Luz]

Hello sorry if this is not the correct place for these questions
I was testing the latest version of Django[1] directly from Github and am 
having this problem.

In this link you can see all the steps I did to get this error

https://asciinema.org/a/9213

I try:

python manage.py makemessages

Result in this: 

*optparse.OptionConflictError: option -e/--extension: conflicting option 
string(s): -e*

That would be a bug or am I doing something wrong



[1] 
https://github.com/django/django/tree/8f6dff372b174e772920de6d82bd085f1a74eaf2

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/97fc2fcc-4ac7-46dd-aef2-9ab42f5608b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.