Re: Experimental APIs DEP

2014-12-06 Thread Carl Meyer 
On 12/06/2014 07:24 PM, Andrew Godwin wrote:
> My notes from the meeting say "experimental API language", so I may have
> taken an adjective too literally when I made this.
> 
> Nevertheless, the key thing _I_ want to see is for us to commit to
> putting release notes out for some of Django's APIs that aren't
> necessarily considered stable. The 1.7 database API stuff was the main
> catalyst for this; those are changes and APIs we should have documented,
> and fall somewhere above "internal" (as we expect people to build
> third-party database backends), but not tie ourselves into a 3-release
> deprecation cycle for.
> 
> How about we change the label from "Experimental" to something like
> "Unstable", but keep the same provisions - documentation called out as
> "unstable feature", separate section in the release notes, etc. That
> establishes a clear level between "internal and we don't care about it"
> and "stable and publicly documented". The alternative is to change the
> DEP to just say we're going to start putting release notes up for
> certain internal APIs, and then somehow list the ones we will somewhere
> (probably on the API stability page).

Something doesn't feel quite right to me about the word "unstable"
either. I guess it's technically applicable to something we want to
retain the freedom to change, but it seems pejorative.

I guess I would favor your latter alternative: don't introduce new
terminology, just document some things (probably starting with the
database backend interface) in the internals/ section of the docs, and
clarify that while APIs documented there are not covered by the
back-compat policy, changes to them will be noted in the release notes.

I don't really think there's a problem with the word "internal" here:
from the perspective of the vast majority of Django users, the database
backend API is internal, but there are a few (maintainers of third-party
backends) for whom its a very important interface, so we document it.

Carl

-- 
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/5483D5BA.3060800%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Experimental APIs DEP

2014-12-06 Thread Andrew Godwin 
My notes from the meeting say "experimental API language", so I may have
taken an adjective too literally when I made this.

Nevertheless, the key thing _I_ want to see is for us to commit to putting
release notes out for some of Django's APIs that aren't necessarily
considered stable. The 1.7 database API stuff was the main catalyst for
this; those are changes and APIs we should have documented, and fall
somewhere above "internal" (as we expect people to build third-party
database backends), but not tie ourselves into a 3-release deprecation
cycle for.

How about we change the label from "Experimental" to something like
"Unstable", but keep the same provisions - documentation called out as
"unstable feature", separate section in the release notes, etc. That
establishes a clear level between "internal and we don't care about it" and
"stable and publicly documented". The alternative is to change the DEP to
just say we're going to start putting release notes up for certain internal
APIs, and then somehow list the ones we will somewhere (probably on the API
stability page).

Andrew

On Sat, Dec 6, 2014 at 1:02 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> On 6 déc. 2014, at 10:05, Carl Meyer  wrote:
>
> > As the DEP notes, our backwards-compatibility policy already includes a
> > longstanding carve-out for anything documented within the "internals"
> > section of the docs. We haven't made much use of this for documenting
> > actual internal APIs (most of that section of the docs is about
> > contribution process), but we could.
>
> Like Carl, I believe “internal” is an established concept that fits our
> needs
> better than “experimental”.
>
> To me “experimental” sounds much like an ill-defined gray zone between
> private and public.
>
> --
> 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/A3D3D45A-19CE-44D4-82DA-84AA45EDA586%40polytechnique.org
> .
> 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFwN1uqV%2BYbu%3DQgCy3W5AC3aFDX_0W4YzUQLT22RH3h01KLLvg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Experimental APIs DEP

2014-12-06 Thread Aymeric Augustin 
On 6 déc. 2014, at 10:05, Carl Meyer  wrote:

> As the DEP notes, our backwards-compatibility policy already includes a
> longstanding carve-out for anything documented within the "internals"
> section of the docs. We haven't made much use of this for documenting
> actual internal APIs (most of that section of the docs is about
> contribution process), but we could.

Like Carl, I believe “internal” is an established concept that fits our needs
better than “experimental”.

To me “experimental” sounds much like an ill-defined gray zone between
private and public.

-- 
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/A3D3D45A-19CE-44D4-82DA-84AA45EDA586%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Fellow Report - December 5, 2014

2014-12-06 Thread Tim Graham 


The release for 1.7.2 didn't happen this week as I had hoped. The team is 
still sorting out how to add new releasers. Maybe next week.


Report for week ending December 5, 2014:

Triaged

---

https://code.djangoproject.com/ticket/2394 - fastcgi with fork method got 
db error (won’t fix)

https://code.djangoproject.com/ticket/23943 - Audit tests decorated with 
unittest.expectedFailure (created)

https://code.djangoproject.com/ticket/23947 - Django's test suite does not 
pass in reverse order (created)

https://code.djangoproject.com/ticket/23952 - Don't run all template tests 
with TEMPLATE_STRING_IF_INVALID='INVALID' (created)

https://code.djangoproject.com/ticket/23944 - Django should use custom 
exceptions for errors thrown by send_mail (etc.), not smtplib.SMTPException 
(won’t fix)

https://code.djangoproject.com/ticket/23949 - Add charset to JsonResponse 
(invalid)

https://code.djangoproject.com/ticket/23965 - FieldFile doesn't mention 
inheritance (fixed)

Authored



https://github.com/django/django/pull/3672 - Fixed #23939 -- Moved session 
verification out of SessionAuthenticationMiddleware.

https://github.com/django/django/pull/3673 - Added a test to verify headers 
set by default middleware; refs #23939.

https://github.com/django/django/pull/3682 - Fixed #23857 -- Fixed admin 
crash with "save as new" and deleting inline

https://github.com/django/django/pull/3683 - Fixed #23920 -- Fixed MySQL 
crash when adding blank=True to TextField.

https://github.com/django/django/pull/3686 - Fixed #23957 -- Started 
deprecation toward requiring session verification

Reviewed/committed

--

https://github.com/django/django/pull/3646 - Fixed #23933 -- Made 
override_settings(DATABASE_ROUTERS) affect the master router.

https://github.com/django/django/pull/3657 - Refs #18586 -- Split up 
model_package.ModelPackageTests

https://github.com/django/django/pull/3641 - Fixed #23929 -- Added more 
tests for create_default_site.

https://github.com/django/django/pull/3647 - Fixed #23807 -- Ignored 
non-digits in psycopg2 version

https://github.com/django/django/pull/3659 - Fixed #23945 -- Made default 
site use the configured SITE_ID.

https://github.com/django/django/pull/3637 - Fixed #23934 -- Fixed 
regression in admin views obj parameter.

https://github.com/django/django/pull/3664 - Fixed #23946 -- Fixed 
runserver crash when socket error contains Unicode chars.

https://github.com/django/django/pull/3631- Fixed #23768 -- Rewrote 
template tests as unit tests

https://github.com/django/django/pull/3651 - Fixed #23935 -- Converted 
decimals to fixed point in utils.numberformat.format

https://github.com/django/django/pull/3668 - Fixed #23950 -- Prevented 
calling deconstruct on classes in MigrationWriter.

https://github.com/django/django/pull/3464 - Fixed #20392 -- Added 
TestCase.setUpTestData()

https://github.com/django/django/pull/3658 - Refs #18586 -- Split up 
model_inheritance.ModelInheritanceTest

https://github.com/django/django/pull/3617 - Fixed #23911 -- Added support 
for buffer file uploads in the test client

https://github.com/django/django/pull/3680 - Fixed #23958 - Rewrote filter 
tests as unit tests.

https://github.com/django/django/pull/3679 - Refs #23947 -- Django's test 
suite doesn't pass in reverse order

Reviews of core dev work



https://github.com/django/django/pull/3685 - Fixed #23954 -- Added special 
text/varchar PostgreSQL indexes in migrations
https://github.com/django/django/pull/3694 - Added RasterSource/GDALBand 
GDAL objects

-- 
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/2ec76d33-fd1b-4485-a158-e5d59e86bfcf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: uuid field short websafe representation

2014-12-06 Thread Michael Manfre 
A non-standard, compressed unique value is not a UUID. Also, this forces
database backends to store the value in a string datatype and doesn't allow
taking advantage of uuid specific datatypes. E.g. Postgresql couldn't use
its uuid datatype. Any data can be made safe for any specific usage, e.g.
URLs, but there is no reason to enforce this requirement in all uses of the
data because not everyone will expose a UUID in a URL.

-1 from me.

Regards,
Michael Manfre

On Sat, Dec 6, 2014 at 11:31 AM, Radek Svarz  wrote:

> Hi, I am glad to see the UUID field coming to 1.8
>
> Bellow is how we do it now in 1.7.
>
> The advantages:
>
>  - it only uses 21 chars (instead of 32)
>
>  - chars are safe for URLs
>
>  - uuid is created when default is called
>
> I advocate to have the short websafe representation. What do you think?
>
> code:
>
>> def safe_uuid():
>> return uuid.uuid4().bytes.encode('base64').rstrip('=\n').replace('/',
>> '_')
>>
>
>
>> class UUIDField(CharField) :
>> """
>> UUIDField stored in 21 Chars
>> Example: uuid = UUIDField(primary_key=True, editable=False)
>> """
>> description = "UUIDField stored in 21 Chars"
>> def __init__(self, *args, **kwargs):
>> kwargs['max_length'] = kwargs.get('max_length', 22 )
>> kwargs['default'] = safe_uuid
>> CharField.__init__(self, *args, **kwargs)
>>
>> def deconstruct(self):
>> name, path, args, kwargs = super(UUIDField, self).deconstruct()
>> return name, path, args, kwargs
>
>
> Radek
>
>  --
> 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/1c29dfae-6483-465c-939e-f4319120781f%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAGdCwBtMjX_OHTkExpd7a8o7VfnG7AvXoV64TOvhoHd2W0_AGA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

uuid field short websafe representation

2014-12-06 Thread Radek Svarz 
Hi, I am glad to see the UUID field coming to 1.8

Bellow is how we do it now in 1.7.

The advantages:

 - it only uses 21 chars (instead of 32)

 - chars are safe for URLs

 - uuid is created when default is called

I advocate to have the short websafe representation. What do you think?

code:

> def safe_uuid():
> return uuid.uuid4().bytes.encode('base64').rstrip('=\n').replace('/', 
> '_')
>
 

> class UUIDField(CharField) :
> """
> UUIDField stored in 21 Chars
> Example: uuid = UUIDField(primary_key=True, editable=False)
> """ 
> description = "UUIDField stored in 21 Chars"
> def __init__(self, *args, **kwargs):
> kwargs['max_length'] = kwargs.get('max_length', 22 )
> kwargs['default'] = safe_uuid 
> CharField.__init__(self, *args, **kwargs)
> 
> def deconstruct(self):
> name, path, args, kwargs = super(UUIDField, self).deconstruct()
> return name, path, args, kwargs


Radek

-- 
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/1c29dfae-6483-465c-939e-f4319120781f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1.7 migrations don't respect db_table in M2M relation

2014-12-06 Thread Tim Graham 
Please use Django's ticket tracker to report bugs in Django: 
https://code.djangoproject.com/newticket

Thanks!

On Saturday, December 6, 2014 8:10:42 AM UTC-5, lza...@ucs.br wrote:
>
>
> Hi,
>
> If is defined "db_table" in Meta class of a model, that you are using by 
> through, the migrations create the table with original name, dosen't 
> respect the db_table attribute defined on through model.
>
> Instead of create table name "myapp_mychoicename" it create 
> "myapp_test_company_related".
>
> class Test(models.Model):
> company_related = models.ManyToManyField(Company,
>   verbose_name='xx',
>   related_name='xxx',
>   through='TestCompany')
>
> class TestCompany(models.Model):
> test = models.ForeignKey(Test)
> company = models.ForeignKey(Company)
>
> class Meta:
> auto_created = Test
> db_table = 'myapp_mychoicename'
>
>
> Enviado via UCSMail.
>

-- 
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/66981e4f-7efe-4f9f-8e92-f7fae413af6b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Ordering of fields in subclasses of a form

2014-12-06 Thread Thomas Tanner 
Hi,
I've submitted a pull request https://github.com/django/django/pull/3652
for the often requested feature "Easy way to customize ordering of
fields on forms that use inheritance".
I'd appreciate some feedback
https://code.djangoproject.com/ticket/5986#comment:32
cheers,

-- 
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/54832845.9010001%40gmx.net.
For more options, visit https://groups.google.com/d/optout.

Django 1.7 migrations don't respect db_table in M2M relation

2014-12-06 Thread lzanuz 

Hi,

If is defined "db_table" in Meta class of a model, that you are using by 
through, the migrations create the table with original name, dosen't 
respect the db_table attribute defined on through model.

Instead of create table name "myapp_mychoicename" it create 
"myapp_test_company_related".

class Test(models.Model):
company_related = models.ManyToManyField(Company,
  verbose_name='xx',
  related_name='xxx',
  through='TestCompany')

class TestCompany(models.Model):
test = models.ForeignKey(Test)
company = models.ForeignKey(Company)

class Meta:
auto_created = Test
db_table = 'myapp_mychoicename'


-- 
Enviado via UCSMail.

-- 
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/3d9fd215-b7a9-4e26-92b5-e50038fb6c15%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Experimental APIs DEP

2014-12-06 Thread Carl Meyer 
Hi Andrew,

Thanks for putting together this proposal.

On 12/05/2014 09:32 PM, Andrew Godwin wrote:
> One of the results of discussions at Django Under The Hood was support
> for the idea of marking APIs "experimental" - that is, document them and
> include them in mainline Django releases, but away from the standard
> Django deprecation cycle while still not hiding them under the
> "Internal" moniker (these would be APIs for public consumption).

I must have missed this discussion at DutH (or my memory is just poor).
I recall discussion of better documenting changes to the database
backends API for the benefit of third-party database backends, but I
don't recall discussion of a new "experimental" designation.

> Of particular interest here is the issues we faced with some of the
> migration APIs during the 1.7 release; 1.7 might have been able to
> release faster if we could have released early with some parts of
> migrations and the schema editor marked as "experimental" and iterated
> on it during the main release cycle, and communicated with third-party
> database backends more effectively and given them documentation and
> release notes.
> 
> There's an extra consideration here if we should extend the proposed
> part of the release notes listing experimental changes to also include
> internal changes, and possibly a separate discussion to be had about
> marking some of the Django database API as stable (or experimental for a
> release or two, then upgrade them).
> 
> The pull request for the DEP is here: https://github.com/django/deps/pull/10

As the DEP notes, our backwards-compatibility policy already includes a
longstanding carve-out for anything documented within the "internals"
section of the docs. We haven't made much use of this for documenting
actual internal APIs (most of that section of the docs is about
contribution process), but we could. What does an "experimental"
designation gain us that the "internals" section doesn't?

(I am hesitant about the term "experimental" -- it implies both that we
don't trust the code in question, and that the code is likely to
"graduate" to fully-backwards-compatible status in the near future. I'm
not sure that those two things will be true in every case of an internal
API that we may want to document.)

Carl

-- 
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/5482C6C3.7030801%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature