Re: PEP 484 type hinting in Django
Hi Tim, do you know if JetBrains still willing to fund the project as the upcoming django 2.1 will only support python 3.5+ that pave the way for inline annotations. On Wednesday, August 17, 2016 at 11:41:03 PM UTC+10, Tim Graham wrote: > > The JetBrains announcement that they want to fund the project isn't a > guarantee that it'll be implemented. The feature needs to go through the > normal feature acceptance process, which as Markus said, might involve a > DEP. > > Assuming the idea is accepted, my sense on timing would be to wait until > January when Django drops support for Python 2.7 and 3.4 in master. Then we > could use inline annotations rather than the stub files. > > Past discussions of type hinting: > https://groups.google.com/d/topic/django-developers/z_P1TvJ6QG8/discussion > https://groups.google.com/d/topic/django-developers/xOTmq93YZuQ/discussion > > On Wednesday, August 17, 2016 at 5:30:56 AM UTC-4, Florian Apolloner wrote: >> >> >> >> On Wednesday, August 17, 2016 at 11:06:47 AM UTC+2, dmoisset wrote: >>> >>> @Florian >>> Would you care to ellaborate? I couldn't find the post you mention >>> (although requests is one of the few 3rd party projects that have support >>> at the official typeshed repository, https://github.com/python/typeshed >>> ) >>> >> >> https://lwn.net/Articles/643269/ and https://lwn.net/Articles/643399/ -- >> might be that things changed by now. >> > -- 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/5cc8eab9-de3b-4eed-a260-7f7845bd8fbe%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Improving usefulness of management command help output via reordering options
+1 Seems sensible to me too! Maybe the common arguments can even be put
under a header like 'common arguments', if argparse allows that.
On 6 April 2018 at 07:31, Carlton Gibson wrote:
> Hi David.
>
> Your suggestion seems sensible, good even. (To me at least. 🙂)
>
> If you'd be happy to do the work for it then a Trac ticket + PR would be
> the way to go.
> (Assuming there are no objections.)
>
> Kind Regards,
>
> Carlton
>
>
> On Friday, 6 April 2018 01:24:12 UTC+2, David Foster wrote:
>>
>> Currently if you run a custom management command with --help, you will
>> get output that looks like:
>>
>> $ python3 manage.py import_layout_calendar --help
>>
>> usage: manage.py import_layout_calendar [-h] [--version] [-v {0,1,2,3}]
>>
>> [--settings SETTINGS]
>>
>> [--pythonpath PYTHONPATH]
>>
>> [--traceback] [--no-color]
>>
>> [--simulate] [--no-strict]
>> [--debug]
>>
>> [--replace] [--fast-validate]
>>
>> [args [args ...]]
>>
>>
>> Imports the calendar for a layout in the database.
>>
>>
>> positional arguments:
>>
>> args
>>
>>
>> optional arguments:
>>
>> -h, --helpshow this help message and exit
>>
>> --version show program's version number and exit
>>
>> -v {0,1,2,3}, --verbosity {0,1,2,3}
>>
>> Verbosity level; 0=minimal output, 1=normal
>> output,
>>
>> 2=verbose output, 3=very verbose output
>>
>> --settings SETTINGS The Python path to a settings module, e.g.
>>
>> "myproject.settings.main". If this isn't
>> provided, the
>>
>> DJANGO_SETTINGS_MODULE environment variable will
>> be
>>
>> used.
>>
>> --pythonpath PYTHONPATH
>>
>> A directory to add to the Python path, e.g.
>>
>> "/home/djangoprojects/myproject".
>>
>> --traceback Raise on CommandError exceptions
>>
>> --no-colorDon't colorize the command output.
>>
>> --simulateSuppress all database modifications
>>
>> --no-strict, -S Do not promote all warnings to errors
>>
>> --debug Perform all validating and importing live,
>> without
>>
>> capturing output
>>
>> --replace Delete the current layout overlay before
>> importing.
>>
>> --fast-validate Disables full simulated import as part of
>> validation
>>
>> I have highlighted in yellow the useful information specific to the
>> command that is *not* boilerplate. Notice that most of this yellow text is
>> at the end of the output, with the boilerplate dominating what the user
>> reads first.
>>
>> I propose reordering the options in the output so that the useful
>> information is at the *beginning* rather than the end, so that it looks
>> more like the following:
>>
>> $ python3 manage.py import_layout_calendar --help
>>
>> usage: manage.py import_layout_calendar [-h] [--simulate] [--no-strict]
>>
>> [--debug] [--replace]
>>
>> [--fast-validate] [--version]
>>
>> [-v {0,1,2,3}] [--settings
>> SETTINGS]
>>
>> [--pythonpath PYTHONPATH]
>>
>> [--traceback] [--no-color]
>>
>> [args [args ...]]
>>
>>
>> Imports the calendar for a layout in the database.
>>
>>
>> positional arguments:
>>
>> args |
>>
>>
>>
>> optional arguments:
>>
>> -h, --helpshow this help message and exit
>>
>> --simulateSuppress all database modifications
>>
>> --no-strict, -S Do not promote all warnings to errors
>>
>> --debug Perform all validating and importing live,
>> without
>>
>> capturing output
>>
>> --replace Delete the current layout overlay before
>> importing.
>>
>> --fast-validate Disables full simulated import as part of
>> validation
>>
>> --version show program's version number and exit
>>
>> -v {0,1,2,3}, --verbosity {0,1,2,3}
>>
>> Verbosity level; 0=minimal output, 1=normal
>> output,
>>
>> 2=verbose output, 3=very verbose output
>>
>> --settings SETTINGS The Python path to a settings module, e.g.
>>
>> "myproject.settings.main". If this isn't
>> provided, the
>>
>> DJANGO_SETTINGS_MODULE environment variable will
>> be
>>
>> used.
>>
>> --pythonpath PYTHONPATH
>>
>> A directory to add to the Python path, e.g.
>>
>> "/home/djan
Re: SafeExceptionReporterFilter should obfuscate all variables in every stack frame below a function decorated with sensitive_variables
My only concern is that it would greatly reduce the usefulness of the
exception reporter, and might lead to people removing the
sensitive_variables decorator in order to see exception tracebacks.
Perhaps rather than obscure all local variables below the decorated
function, we could obscure any variable with the same *value* as a
sensitively marked variable in the call stack? This would work better with
strings than say dictionaries, but it could be a good middle ground.
Tom
On Wed, 4 Apr 2018, 21:05 ncvc via Django developers (Contributions to
Django itself), wrote:
> SafeExceptionReporterFilter obfuscates variables in the function decorated
> with sensitive_variables, but it does not obfuscate variables lower in the
> call stack, which could result in sensitive data being leaked in exception
> reports.
>
> For instance:
>
> @sensitive_variables('sensitive')
> def decorated_function():
> sensitive = 'something sensitive'
> undecorated_function(sensitive)
>
> def undecorated_function(var):
> raise Exception()
>
>
> In this code, the "sensitive" variable will be obfuscated in
> the decorated_function stack frame, but "var" in the undecorated_function
> stack frame will not, resulting in the sensitive data being leaked in the
> report. If we wrote undecorated_function, then we can just decorate the
> function ourselves, but if it's from a third-party package, we are unable
> to decorate it.
>
> The solution here is to obfuscate _all_ variables in all stack frames
> below a function decorated with sensitive_variables, since these functions
> can do arbitrary things with the sensitive data. I've written a custom
> SafeExceptionReporterFilter that does this for the company I work for, and
> I think it would be a good behavior to adopt in core Django.
>
> Any thoughts or concerns with this approach?
>
>
> This message, including any attachments, is a PRIVATE communication, which
> may contain confidential, legally privileged, and/or proprietary
> information. If you are not the intended recipient, you are hereby
> notified that any dissemination, disclosure, copying, distribution or use
> of the information contained in or attached to this message is strictly
> prohibited. Please notify the sender of the delivery error by replying to
> this message, and then permanently delete it from your system. Unless
> explicitly stated to the contrary, nothing contained in this message shall
> constitute an offer to buy or sell, or a solicitation of an offer to buy or
> sell, any security, property interest or other asset, nor shall it
> constitute a binding obligation of any kind, an official confirmation of
> any transaction or an official statement of Cadre.
>
> Cadre may monitor, review and retain email communications traveling
> through its networks or systems, AND CADRE IS NOT OBLIGATED TO RESTRICT THE
> USE OR DISCLOSURE OF ANY INFORMATION SENT TO IT BY YOU VIA E-MAIL
> COMMUNICATION.
>
> --
> 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/7376ab0c-530c-42d8-9cfb-6c829af21098%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/CAFNZOJNPoU0S2_44S3frL4%2BdkjYqOXYEw%2BRP4-tT1z_Lx%2BuRqg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: PEP 484 type hinting in Django
To the best of my knowledge JetBrains fundled the money to Django for that specific purpose -- so yes the funding should be here if needed. That said, there is no decission on a) whether we actually want type hints and b) if the should be inline or stubs. Those two points have to be cleared first. Cheers, Florian On Friday, April 6, 2018 at 9:11:04 AM UTC+2, Eddy C wrote: > > Hi Tim, do you know if JetBrains still willing to fund the project as the > upcoming django 2.1 will only support python 3.5+ that pave the way for > inline annotations. > > On Wednesday, August 17, 2016 at 11:41:03 PM UTC+10, Tim Graham wrote: >> >> The JetBrains announcement that they want to fund the project isn't a >> guarantee that it'll be implemented. The feature needs to go through the >> normal feature acceptance process, which as Markus said, might involve a >> DEP. >> >> Assuming the idea is accepted, my sense on timing would be to wait until >> January when Django drops support for Python 2.7 and 3.4 in master. Then we >> could use inline annotations rather than the stub files. >> >> Past discussions of type hinting: >> https://groups.google.com/d/topic/django-developers/z_P1TvJ6QG8/discussion >> https://groups.google.com/d/topic/django-developers/xOTmq93YZuQ/discussion >> >> On Wednesday, August 17, 2016 at 5:30:56 AM UTC-4, Florian Apolloner >> wrote: >>> >>> >>> >>> On Wednesday, August 17, 2016 at 11:06:47 AM UTC+2, dmoisset wrote: @Florian Would you care to ellaborate? I couldn't find the post you mention (although requests is one of the few 3rd party projects that have support at the official typeshed repository, https://github.com/python/typeshed ) >>> >>> https://lwn.net/Articles/643269/ and https://lwn.net/Articles/643399/ >>> -- might be that things changed by now. >>> >> -- 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/6f2b5dd9-f8e6-4b67-8e25-585cbd802413%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: SafeExceptionReporterFilter should obfuscate all variables in every stack frame below a function decorated with sensitive_variables
The issue with obscuring any values that equal the sensitive variable is
that functions can do arbitrary things to the data, e.g. splitting a name
into first and last, combining first and last name strings into a full
name, stripping whitespace, generating a SQL query with the sensitive data,
etc. that would cause the value to be not equal but would still leak the
sensitive data. For us (and I suspect most companies using
sensitive_variables to obscure PII), the tradeoff of less useful stack
traces is worth not sending PII to developers via email.
We could add a kwarg to the sensitive_variables decorator to opt in to this
behavior, though I think the default behavior should be to obscure all
variables below the decorated function, as the current implementation can
easily leak sensitive data even when using the decorator.
On Fri, Apr 6, 2018 at 5:01 AM Tom Forbes wrote:
> My only concern is that it would greatly reduce the usefulness of the
> exception reporter, and might lead to people removing the
> sensitive_variables decorator in order to see exception tracebacks.
>
> Perhaps rather than obscure all local variables below the decorated
> function, we could obscure any variable with the same *value* as a
> sensitively marked variable in the call stack? This would work better with
> strings than say dictionaries, but it could be a good middle ground.
>
> Tom
>
> On Wed, 4 Apr 2018, 21:05 ncvc via Django developers (Contributions to
> Django itself), wrote:
>
>> SafeExceptionReporterFilter obfuscates variables in the function
>> decorated with sensitive_variables, but it does not obfuscate variables
>> lower in the call stack, which could result in sensitive data being leaked
>> in exception reports.
>>
>> For instance:
>>
>> @sensitive_variables('sensitive')
>> def decorated_function():
>> sensitive = 'something sensitive'
>> undecorated_function(sensitive)
>>
>> def undecorated_function(var):
>> raise Exception()
>>
>>
>> In this code, the "sensitive" variable will be obfuscated in
>> the decorated_function stack frame, but "var" in the undecorated_function
>> stack frame will not, resulting in the sensitive data being leaked in the
>> report. If we wrote undecorated_function, then we can just decorate the
>> function ourselves, but if it's from a third-party package, we are unable
>> to decorate it.
>>
>> The solution here is to obfuscate _all_ variables in all stack frames
>> below a function decorated with sensitive_variables, since these functions
>> can do arbitrary things with the sensitive data. I've written a custom
>> SafeExceptionReporterFilter that does this for the company I work for, and
>> I think it would be a good behavior to adopt in core Django.
>>
>> Any thoughts or concerns with this approach?
>>
>>
>> This message, including any attachments, is a PRIVATE communication,
>> which may contain confidential, legally privileged, and/or proprietary
>> information. If you are not the intended recipient, you are hereby
>> notified that any dissemination, disclosure, copying, distribution or use
>> of the information contained in or attached to this message is strictly
>> prohibited. Please notify the sender of the delivery error by replying to
>> this message, and then permanently delete it from your system. Unless
>> explicitly stated to the contrary, nothing contained in this message shall
>> constitute an offer to buy or sell, or a solicitation of an offer to buy or
>> sell, any security, property interest or other asset, nor shall it
>> constitute a binding obligation of any kind, an official confirmation of
>> any transaction or an official statement of Cadre.
>>
>> Cadre may monitor, review and retain email communications traveling
>> through its networks or systems, AND CADRE IS NOT OBLIGATED TO RESTRICT THE
>> USE OR DISCLOSURE OF ANY INFORMATION SENT TO IT BY YOU VIA E-MAIL
>> COMMUNICATION.
>>
>> --
>> 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/7376ab0c-530c-42d8-9cfb-6c829af21098%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 p
Shouldn't manage.py call python3 instead of python?
The header of manage.py has: #!/usr/bin/env python Shoudn’t it be: #!/usr/bin/env python3 Since 2.0 is now only Python3. Both my Mac OS & FreeBSD environments have Python 3.5+ as “python3". (I’m not sure about Linux or other environments). Is that a bug I need to file? -bobby -- 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/C158A05A-0DA3-485D-861E-B72DA11E5074%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Shouldn't manage.py call python3 instead of python?
I think you're right and PEP394 is the relevant text: https://www.python.org/dev/peps/pep-0394/ TL;DR For now, *python* should refer to python2 and *python3* should be used to refer to python 3. On Saturday, 7 April 2018 07:07:35 UTC+10, Bobby Mozumder wrote: > > The header of manage.py has: #!/usr/bin/env python > > Shoudn’t it be: #!/usr/bin/env python3 > > Since 2.0 is now only Python3. Both my Mac OS & FreeBSD environments have > Python 3.5+ as “python3". (I’m not sure about Linux or other environments). > > Is that a bug I need to file? > > -bobby > -- 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/d13b010f-df53-46eb-8dab-93b4fc05dd97%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Shouldn't manage.py call python3 instead of python?
It was tried in https://code.djangoproject.com/ticket/27878 but it caused problems, particularly on Windows. On Friday, April 6, 2018 at 6:35:50 PM UTC-4, Josh Smeaton wrote: > > I think you're right and PEP394 is the relevant text: > https://www.python.org/dev/peps/pep-0394/ > > TL;DR > > For now, *python* should refer to python2 and *python3* should be used to > refer to python 3. > > On Saturday, 7 April 2018 07:07:35 UTC+10, Bobby Mozumder wrote: >> >> The header of manage.py has: #!/usr/bin/env python >> >> Shoudn’t it be: #!/usr/bin/env python3 >> >> Since 2.0 is now only Python3. Both my Mac OS & FreeBSD environments have >> Python 3.5+ as “python3". (I’m not sure about Linux or other environments). >> >> Is that a bug I need to file? >> >> -bobby >> > -- 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/7cdf48bb-ab0b-449d-8f33-a4c6d369%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
