Re: [Django] #26033: Add argon2 password hasher

2016-01-10 Thread Django 
#26033: Add argon2 password hasher
--+
 Reporter:  timgraham |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by adrianmoisey):

 * cc: adrianmoisey (added)


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.b703e9c38a8e8e6a2ddeb9c57d062fc8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26066: Admin handles a table of models being wider than the screen badly

2016-01-10 Thread Django 
#26066: Admin handles a table of models being wider than the screen badly
-+-
 Reporter:  chozabu  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  admin css style  | Triage Stage:
  layout |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-
Changes (by elky):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Thanks for reporting!

 Removing `overflow: auto` makes results table overlapped by a filter
 sidebar (if you have filter setting in your admin.py of course). So this
 needs more tricky UX solution.

 I had similar problem on one of the projects and I consulted with UX guy
 who just advised me to hide some of less-informative columns or display
 shorted info (like ''B. Obama'' instead of ''Barack Obama'') to save
 space.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.4da0f53d3d5577ad5105c2dda0241af9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26063: Regression in Django 1.9: SQLite can no longer handle more than 2000 values in a "foo__in" filter

2016-01-10 Thread Django 
#26063: Regression in Django 1.9: SQLite can no longer handle more than 2000 
values
in a "foo__in" filter
-+-
 Reporter:  rhertzog |Owner:  aaugustin
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 Let's assume a statement with C columns and P parameters. With the current
 implementation, on SQLite, when `DEBUG = True`:

 (1) The statement itself is executed: C columns, P parameters. This
 requires `C ≤ SQLITE_MAX_COLUMN` and `P ≤ SQLITE_MAX_VARIABLE_NUMBER`.

 (2) Another statement is executed to escape the parameters: P columns, P
 parameters. This requires `P ≤ MIN(SQLITE_MAX_COLUMN,
 SQLITE_MAX_VARIABLE_NUMBER)`

 The default values of SQLite are `SQLITE_MAX_COLUMN = 2000 >
 SQLITE_MAX_VARIABLE_NUMBER = 999`. With these values,
 `MIN(SQLITE_MAX_COLUMN, SQLITE_MAX_VARIABLE_NUMBER) =
 SQLITE_MAX_VARIABLE_NUMBER`. As a consequence, any statement that will go
 through (1) without raising an exception will also go through (2) without
 raising an exception.

 In your example, C = 1 and P = 2000. This will fail at step (1) with
 SQLite's default values. It will reproduce the original reporter's
 problem, but only on platforms where `SQLITE_MAX_VARIABLE_NUMBER` has been
 increased to over 2000.

 We need the test to pass or be skipped on all platforms, though.

 I see two ways to achieve this:

 - detecting the values of `SQLITE_MAX_COLUMN` and
 `SQLITE_MAX_VARIABLE_NUMBER` and ajusting accordingly — which doesn't seem
 possible in Python
 - writing a test just for (2), without going through (1) — which I did.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.5b0343c462269ff9a3dbc663a02e6b9a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26063: Regression in Django 1.9: SQLite can no longer handle more than 2000 values in a "foo__in" filter

2016-01-10 Thread Django 
#26063: Regression in Django 1.9: SQLite can no longer handle more than 2000 
values
in a "foo__in" filter
-+-
 Reporter:  rhertzog |Owner:  aaugustin
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by shaib):

 Replying to [comment:10 aaugustin]:
 > Shai: the problem in that case is that there's no way to tell apart
 these two cases:
 >
 > - `cursor.execute()` raised `OperationalError` because
 `SQLITE_MAX_VARIABLE_NUMBER = 999` (the default value) and the query
 contains more than 999 parameters
 > - `cursor.execute()` raised `OperationalError` while attempting to
 generate the representation of the last query because of the bug reported
 in this ticket

 ...but the statement I gave only has one column. It will never fail over
 the bug, only on number of variables.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.6058ee307ef0c27bfe99ad7deb1251e9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21113: django_admin_log table stores messages in different languages depending on which language was active while editing.

2016-01-10 Thread Django 
#21113: django_admin_log table stores messages in different languages depending 
on
which language was active while editing.
-+-
 Reporter:  dimyur27@…   |Owner:  Claude
 |  Paroz 
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  admin logs i18n  | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz ):

 In [changeset:"4a03e6f27207ec7d9bb12d229da570633c086a92" 4a03e6f2]:
 {{{
 #!CommitTicketReference repository=""
 revision="4a03e6f27207ec7d9bb12d229da570633c086a92"
 Refs #21113 -- Updated test to allow for bad MySQL time resolution
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/076.cd2a8a7ac296470f14cef6500783f72a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26064: Move migration operation reduction logic to their respective class.

2016-01-10 Thread Django 
#26064: Move migration operation reduction logic to their respective class.
-+-
 Reporter:  charettes|Owner:  charettes
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by charettes):

 > To put my skepticism in brief: is it actually easier to write that
 reduce method in advance, anticipating all the various schema alterations
 that might surround your operation and how you'd return an adjusted
 version of your operation to account for them, than it is to just take
 care of it manually when squashing? Even if you're using
 "squashmigrations" rather than the "full reset" approach, "taking care of
 it manually" is just a matter of removing the data migration, adjusting
 its successor to point to its parent, then squashing, then re-appending
 (and modifying as necessary) the data migration. Squashing is done
 infrequently enough that I have a hard time imagining when I'd actually
 choose to write and test a fully parametrized operation with a custom
 reduce method instead of just doing that manual dance every now and then.
 Maybe I just don't use initial-data migrations enough? Or don't squash
 frequently enough?

 Thanks for your feedback Carl. I agree that for most experienced
 developers among us this won't be a game changer. As you said we can
 easily figure out where the non-elidable migration has to be moved or how
 it should be adjusted.

 However I think it can make a significant difference for third-party
 applications and large projects where non experienced developers still
 have to squash their migrations on their own once there is too many of
 them. Such an addition could benefit such users as more experienced
 developers could make the whole process a no brainer, the operation would
 take care of itself.

 For example, the `HStoreExtension` and `HStoreField` case would be a good
 candidate for such an addition.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.0c67d4ec44afdc962b05520eed4da103%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26063: Regression in Django 1.9: SQLite can no longer handle more than 2000 values in a "foo__in" filter

2016-01-10 Thread Django 
#26063: Regression in Django 1.9: SQLite can no longer handle more than 2000 
values
in a "foo__in" filter
-+-
 Reporter:  rhertzog |Owner:  aaugustin
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

 * needs_better_patch:  0 => 1


Comment:

 Marking the patch as needing improvement based on tobald's comment.

 Unfortunately I cannot determine what happens based on code inspection.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.1bd9681144012996f154351882f0a427%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26063: Regression in Django 1.9: SQLite can no longer handle more than 2000 values in a "foo__in" filter

2016-01-10 Thread Django 
#26063: Regression in Django 1.9: SQLite can no longer handle more than 2000 
values
in a "foo__in" filter
-+-
 Reporter:  rhertzog |Owner:  aaugustin
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 Well we could look at the exception message. The former gives "too many
 SQL variables"; I assume the latter gives something else.

 Unfortunately I don't have access to a Debian system affected by this non-
 standard configuration right now, so I cannot reproduce the issue easily.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.ad8a3a1a1ba2ba671cb467a91be92d73%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26063: Regression in Django 1.9: SQLite can no longer handle more than 2000 values in a "foo__in" filter

2016-01-10 Thread Django 
#26063: Regression in Django 1.9: SQLite can no longer handle more than 2000 
values
in a "foo__in" filter
-+-
 Reporter:  rhertzog |Owner:  aaugustin
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 Shai: the problem in that case is that there's no way to tell apart these
 two cases:

 - `cursor.execute()` raised `OperationalError` because
 `SQLITE_MAX_VARIABLE_NUMBER = 999` (the default value) and the query
 contains more than 999 parameters
 - `cursor.execute()` raised `OperationalError` while attempting to
 generate the representation of the last query because of the bug reported
 in this ticket

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.af9e8951037577ce2bae50360adf32f9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26066: Admin handles a table of models being wider than the screen badly

2016-01-10 Thread Django 
#26066: Admin handles a table of models being wider than the screen badly
---+
 Reporter:  chozabu|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.admin  |Version:  1.9
 Severity:  Normal |   Keywords:  admin css style layout
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  1  |  UI/UX:  1
---+
 The main problem is either long bits of text OR large numbers of columns
 causing the table to become wider than the screen.

 With the current overflow settings, this means an admin has to scroll to
 the bottom of the page to find the slider - which is boarding on unusable

 My current solution is to duplicate "changelists.css" into my own project,
 and alter this part:
 {{{
 #changelist-form .results {
   /*overflow-x: auto;*/
 }
 }}}
 Simply removing the overflow method means the  page is wider than the
 screen, and an admin can now easily scroll left and right.
 This is not a very clean solution but *vastly* preferable to current
 situation!


 Making the problem worse, is even a column of single digit numbers can be
 very wide if the column header is a few words long. My solution to this is
 as follows:
 {{{
 #changelist table thead th {
 padding: 0;
 /*white-space: nowrap;*/
 vertical-align: middle;
 }
 }}}
 This allows the headings to wrap - saving loads of space in several
 situations.

 This seems to be an issue quite a few people were struggling with on
 stackoverflow, and is my first bug report. (On that note, Django is
 fantastic, this minor issue with default styling is my biggest complaint
 after months!)

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.49bcd14014b9f40225fd19f6e9108b79%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26020: Standardize restructed text header convention in docs

2016-01-10 Thread Django 
#26020: Standardize restructed text header convention in docs
--+
 Reporter:  timgraham |Owner:  elif
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+

Comment (by elif):

 I'm working on the subheadings.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.85d69ebafb1ab84a7c6ceef288f05560%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26063: Regression in Django 1.9: SQLite can no longer handle more than 2000 values in a "foo__in" filter

2016-01-10 Thread Django 
#26063: Regression in Django 1.9: SQLite can no longer handle more than 2000 
values
in a "foo__in" filter
-+-
 Reporter:  rhertzog |Owner:  aaugustin
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by tobald):

 Aymeric Augustin wrote:
 > If the reporter could test it and confirm that it fixes the issue, that
 would be great.

 I get an error futher:

 {{{
   File "/usr/lib/python2.7/dist-packages/django/db/models/query.py",
 line 258, in __iter__
 self._fetch_all()
   File "/usr/lib/python2.7/dist-packages/django/db/models/query.py",
 line 1074, in _fetch_all
 self._result_cache = list(self.iterator())
   File "/usr/lib/python2.7/dist-packages/django/db/models/query.py",
 line 52, in __iter__
 results = compiler.execute_sql()
   File "/usr/lib/python2.7/dist-
 packages/django/db/models/sql/compiler.py", line 852, in execute_sql
 cursor.execute(sql, params)
   File "/usr/lib/python2.7/dist-packages/django/db/backends/utils.py",
 line 83, in execute
 sql = self.db.ops.last_executed_query(self.cursor, sql, params)
   File "/usr/lib/python2.7/dist-
 packages/django/db/backends/sqlite3/operations.py", line 141, in
 last_executed_query
 return sql % params
 TypeError: not enough arguments for format string
 }}}

 Here params is a list of 25000 integers.

 Thanks,
 Christophe

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.dcbe48e3b84fe4489a4152308b5860af%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26063: Regression in Django 1.9: SQLite can no longer handle more than 2000 values in a "foo__in" filter

2016-01-10 Thread Django 
#26063: Regression in Django 1.9: SQLite can no longer handle more than 2000 
values
in a "foo__in" filter
-+-
 Reporter:  rhertzog |Owner:  aaugustin
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by tobald):

 * cc: d@… (added)


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.187032ac52ac60a84bed9bc1fc20c840%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26063: Regression in Django 1.9: SQLite can no longer handle more than 2000 values in a "foo__in" filter

2016-01-10 Thread Django 
#26063: Regression in Django 1.9: SQLite can no longer handle more than 2000 
values
in a "foo__in" filter
-+-
 Reporter:  rhertzog |Owner:  aaugustin
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by shaib):

 Replying to [comment:4 aaugustin]:
 > I'm stuck writing tests for this.
 >
 > The problem only occurs when SQLITE_MAX_VARIABLE_NUMBER has been changed
 to be greated than SQLITE_MAX_COLUMN, which isn't the default, and there's
 no way to introspect these values -- the Python bindings don't expose the
 `get_limit` API of sqlite.

 It is enough, I think, to try to generate a query with 2001 variables and
 see if it works. That may be less accurate for the reasons, but it checks
 the symptoms, and doesn't need private APIs. `cursor.execute('select %s' +
 sum(2000*[' + %s']), 2001*[1])` or something like that.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.88e7387566ae0ec84fcc765ea06a6a0a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26065: psycopg2 __init__ reports an error: DLL load failed: The specified module could not be found

2016-01-10 Thread Django 
#26065: psycopg2  __init__ reports an error: DLL load failed: The specified 
module
could not be found
-+-
 Reporter:  alvigilegner |Owner:
 Type:  Uncategorized|   Status:  closed
Component:  contrib.postgres |  Version:  1.9
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  psycopg2, Windows| Triage Stage:
  10, __init___, postgres|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by shaib):

 * status:  new => closed
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0
 * resolution:   => invalid


Old description:

> I am unable to use PostGresql with Django on my Windows 10 installation.
> The error is traced back to __init__.py of psycopg2, line 50:
> psycopg2._psycopg import BINARY, NUMBER, STRING, DATETIME, ROWID.
>
> I suspect this is some kind of DLL incompatibility.  I am using PostGres
> 9.2, Python 3.5.1, and Django 1.9 on a Windows 10 PC.  Have tried to
> install psycgp2 from pip and the exe file with the same result.
>
> Does any one out there know of a combination of these three programs that
> works?  This issue has been reported on and off for years, but none of
> the solutions that I have run across do not work for me.

New description:

 I am unable to use PostGresql with Django on my Windows 10 installation.
 The error is traced back to `__init__.py` of psycopg2, `line 50:
 psycopg2._psycopg import BINARY, NUMBER, STRING, DATETIME, ROWID`.

 I suspect this is some kind of DLL incompatibility.  I am using PostGres
 9.2, Python 3.5.1, and Django 1.9 on a Windows 10 PC.  Have tried to
 install psycgp2 from pip and the exe file with the same result.

 Does any one out there know of a combination of these three programs that
 works?  This issue has been reported on and off for years, but none of the
 solutions that I have run across do not work for me.

--

Comment:

 I sympathize with your hardships, and yet I see no problem with Django
 reported here. There might be one if you were able to use psycopg2 from
 Python outside Django, and only had a problem with Django, but I see
 nothing like that in the report.

 If you can show there actually is some problem with Django, feel free to
 reopen. Otherwise, the Django issue tracker is not the place to ask for
 help.

 You can try the django-users mailing list, or some psycopg2 forums.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.fa9eab5ae82f5bb58793c208d9862088%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.