Re: extra files in startproject

On Friday, April 13, 2012 6:49:32 AM UTC+2, Alex Ogier wrote: > > I have seen setup.py's that use remove_tree as part of a "clean" command > to allow someone to run "setup.py clean && setup.py install" to obtain > a pristine distribution idempotently, which I think is a good idea. > No, they shou

Re: extra files in startproject

On Thu, Apr 12, 2012 at 11:56 PM, Ben Finney wrote: > > Alex Ogier writes: > > > That seems like too much to ask. "setup.py install" should Just > > Work(tm), > > In the absence of a proper package management system (as implemented in > operating systems that solved this problem decades ago), you

Re: extra files in startproject

Alex Ogier writes: > That seems like too much to ask. "setup.py install" should Just > Work(tm), In the absence of a proper package management system (as implemented in operating systems that solved this problem decades ago), you can't expect it to Just Work. Parallel installation of multiple ve

Re: django db library doesn't handle quoted table/field names

On Thu, Apr 12, 2012 at 9:14 PM, Craig Lucas wrote: > i actually didnt try the db_column attribute because I read about quoting it > before I started writing the code. But that wont solve the schema problem. >  It will still try to create the index and fk constraints with the dots and > quotes aro

Re: extra files in startproject

On Fri, Apr 13, 2012 at 8:30 AM, Carl Meyer wrote: > Hi Alex, > > On 04/12/2012 04:23 PM, Alex Ogier wrote: > > On Apr 12, 2012 6:16 PM, "Carl Meyer" > > wrote: > [...] > I still think the right solution is to encourage (via the documentation) > installation practices

Re: django db library doesn't handle quoted table/field names

i actually didnt try the db_column attribute because I read about quoting it before I started writing the code. But that wont solve the schema problem. It will still try to create the index and fk constraints with the dots and quotes around the table name. i believe it is required to quote the sc

Re: django db library doesn't handle quoted table/field names

On Thu, Apr 12, 2012 at 3:06 PM, Craig Lucas wrote: > i have developed a database for a client that uses camel casing in the > database. we are now trying to get a models.py file to mimic the > database structure and i have run into a few bugs with regards to > using quoted table names. > > The fi

Re: extra files in startproject

Hi Alex, On 04/12/2012 04:23 PM, Alex Ogier wrote: > On Apr 12, 2012 6:16 PM, "Carl Meyer" > wrote: >> The correct solution is to warn people away from using installation >> techniques in ways they were not intended to be used, and that don't >> work correctly. Repeated u

Re: extra files in startproject

On Apr 12, 2012 6:16 PM, "Carl Meyer" wrote: > > The correct solution is to warn people away from using installation > techniques in ways they were not intended to be used, and that don't > work correctly. Repeated use of "setup.py install" without removing the > previously-installed version is in

Re: extra files in startproject

On 04/12/2012 03:27 PM, Alex Ogier wrote: > That seems like too much to ask. "setup.py install" should Just > Work(tm), and if django requires that a certain directory be clean of > any .py files in order to function properly then "setup.py install" > should make that happen. The note might still b

django db library doesn't handle quoted table/field names

i have developed a database for a client that uses camel casing in the database. we are now trying to get a models.py file to mimic the database structure and i have run into a few bugs with regards to using quoted table names. The first issue is when you specify a foreign key field it takes the t

Re: extra files in startproject

On 04/12/2012 03:16 PM, Aymeric Augustin wrote: > This problem occurs at least when you run "setup.py install" before > and after the commit that introduced the new project layout. > > Some people who had the habit of running "setup.py install" from a > git clone to keep up-to-date with the develo

Re: extra files in startproject

That seems like too much to ask. "setup.py install" should Just Work(tm), and if django requires that a certain directory be clean of any .py files in order to function properly then "setup.py install" should make that happen. The note might still be valuable, because we should inform people that u

Re: extra files in startproject

On 12 avr. 2012, at 21:16, Carl Meyer wrote: > The open question is just how this situation occurs in the first place. > In other words, which particular buggy installer or installation > technique is causing an overlaid installation like that, so we can warn > people away from it and better advis

Re: #18094: signals, model inheritance, and proxy models

On Apr 12, 9:58 pm, Carl Meyer wrote: > So this is an argument against firing the init signals multiple times, > for each superclass, but it's not an argument against changing the > signal framework to include superclass receivers, as proposed in #9318; > that would not change the performance char

Re: #18094: signals, model inheritance, and proxy models

I think changing when signals fire is bound to cause breakages for some apps, and of the worst variety because signals both deal with basic data integrity and are relatively opaque (I.e. debugging is a pain). Even if the current behavior isn't what we would choose given a blank slate, it can't real

Re: extra files in startproject

Hi Alex, On 04/12/2012 01:07 PM, Alex Ogier wrote: > Maybe it would be worth experimenting with various combinations of > django 1.x django-admin.py executables with django 1.4 libraries? Maybe > if django-admin.py is a symlink into a 1.3 tree but django 1.4 is on the > search path this stuff coul

Re: extra files in startproject (was: Django is not a serious framework, really)

Maybe it would be worth experimenting with various combinations of django 1.x django-admin.py executables with django 1.4 libraries? Maybe if django-admin.py is a symlink into a 1.3 tree but django 1.4 is on the search path this stuff could crop up? Best, Alex Ogier On Apr 12, 2012 2:32 PM, "Carl

Re: #18094: signals, model inheritance, and proxy models

On 04/12/2012 12:43 PM, Anssi Kääriäinen wrote: > It is important that pre/post init signals will not get more expensive > than they currently are. Even now they can give around 100% overhead > to model.__init__(). And this is in a case where the currently > initialized model has no signals attache

Re: #18094: signals, model inheritance, and proxy models

It is important that pre/post init signals will not get more expensive than they currently are. Even now they can give around 100% overhead to model.__init__(). And this is in a case where the currently initialized model has no signals attached at all - it is enough that _some_ model in the project

Re: extra files in startproject (was: Django is not a serious framework, really)

Hi Jason, On 04/11/2012 06:10 AM, Jason Ma wrote: > Hi, > I download and tried to use the Django 1.4 yesterday. I am a dummy > and I just follow the official document, but When I just start a > project. > I found that it is what I see from my computer: > > jason@jason-pc:~/workspace/hunqing$

Re: #18094: signals, model inheritance, and proxy models

On Thu, Apr 12, 2012 at 12:19 PM, Carl Meyer wrote: > Also, it isn't really true that the model signals are strictly tied to > database activity; they are tied to events on Python model objects. One > of the three signals under discussion is the pre/post_init signal, which > fires anytime a model

Re: #18094: signals, model inheritance, and proxy models

On 04/12/2012 11:02 AM, Javier Guerra Giraldez wrote: > IOW, i think the existing signals are database-related and should be > fired only for the concrete part(s). if the abstract part wants to, > it can send custom signals. Also, it isn't really true that the model signals are strictly tied to d

Re: #18094: signals, model inheritance, and proxy models

On 04/12/2012 11:02 AM, Javier Guerra Giraldez wrote: > in my mental model, there are three types of inheritance: > > concrete: two tables, deletion should fire two signals, one for the > child record and one for the parent record. > > abstract: there's no parent table, deletion should fire one s

Re: #18094: signals, model inheritance, and proxy models

On 04/12/2012 10:52 AM, Jeremy Dunck wrote: > On Thu, Apr 12, 2012 at 9:31 AM, Carl Meyer wrote: >> There's a discussion ongoing on ticket #18094 >> (https://code.djangoproject.com/ticket/18094) that has enough potential >> back-compat implications that it seems worth getting feedback here. > > S

Re: #18094: signals, model inheritance, and proxy models

On Thu, Apr 12, 2012 at 11:31 AM, Carl Meyer wrote: > Thoughts? in my mental model, there are three types of inheritance: concrete: two tables, deletion should fire two signals, one for the child record and one for the parent record. abstract: there's no parent table, deletion should fire one s

Re: #18094: signals, model inheritance, and proxy models

On Thu, Apr 12, 2012 at 9:31 AM, Carl Meyer wrote: > Hi all, > > There's a discussion ongoing on ticket #18094 > (https://code.djangoproject.com/ticket/18094) that has enough potential > back-compat implications that it seems worth getting feedback here. Small note, I'll try to respond to the who

#18094: signals, model inheritance, and proxy models

Hi all, There's a discussion ongoing on ticket #18094 (https://code.djangoproject.com/ticket/18094) that has enough potential back-compat implications that it seems worth getting feedback here. Currently, when you delete a concrete-inheritance child model instance, pre_delete and post_delete sign