Shouldn't Textarea be CamelCased as TextArea?
Hi guys, I was just wondering, and maybe my English language skills are insufficient. Django defines several widgets, like: TextInput PasswordInput HiddenInput DateInput DateTimeInput TimeInput Textarea Why isn't Textarea CamelCased: TextArea, like the other widgets? It seems inconsistent. But maybe I am missing something? -- Wim -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/1V71BI3iUBQJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Shouldn't Textarea be CamelCased as TextArea?
It's probably just a wart from HTML. The XyzInput widgets correspond more or less to tags, but the Textarea widget corresponds to . There's only two tags like this that are HTML form elements but are not tags, the other being , whose widget "Select" similarly has one capital letter and no "Input" suffix. So the naming is consistent, and agrees with the HTML tags, even though it looks a little weird without that knowledge. Best, Alex Ogier On Sat, Jan 19, 2013 at 3:26 AM, Wim Feijen wrote: > Hi guys, > > I was just wondering, and maybe my English language skills are > insufficient. > > Django defines several widgets, like: > TextInput > PasswordInput > HiddenInput > DateInput > DateTimeInput > TimeInput > Textarea > > Why isn't Textarea CamelCased: TextArea, like the other widgets? It seems > inconsistent. But maybe I am missing something? > > -- Wim > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/1V71BI3iUBQJ. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- 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, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Shouldn't Textarea be CamelCased as TextArea?
Yes, it's a wart from HTML. Even if we were inclined to alter the name to make it idiomatic Python (which isn't necessarily a good idea in this case -- the HTML naming convention makes sense), it would be impractical to change it at this point in Django's lifecycle - there is so much code depending on the old naming that a change would represent a massive disruption for no real gain. Yours, Russ Magee %-) On Sat, Jan 19, 2013 at 10:50 PM, Alex Ogier wrote: > It's probably just a wart from HTML. The XyzInput widgets correspond more > or less to tags, but the Textarea widget corresponds to > . There's only two tags like this that are HTML form elements but > are not tags, the other being , whose widget "Select" > similarly has one capital letter and no "Input" suffix. So the naming is > consistent, and agrees with the HTML tags, even though it looks a little > weird without that knowledge. > > Best, > Alex Ogier > > > On Sat, Jan 19, 2013 at 3:26 AM, Wim Feijen wrote: > >> Hi guys, >> >> I was just wondering, and maybe my English language skills are >> insufficient. >> >> Django defines several widgets, like: >> TextInput >> PasswordInput >> HiddenInput >> DateInput >> DateTimeInput >> TimeInput >> Textarea >> >> Why isn't Textarea CamelCased: TextArea, like the other widgets? It seems >> inconsistent. But maybe I am missing something? >> >> -- Wim >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msg/django-developers/-/1V71BI3iUBQJ. >> To post to this group, send email to django-developers@googlegroups.com. >> To unsubscribe from this group, send email to >> django-developers+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/django-developers?hl=en. >> > > -- > 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, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- 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, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Reminder: pending Oracle fixes and issues
On Thursday 17 January 2013, Anssi Kääriäinen wrote:
> On 17 tammi, 15:50, Shai Berger wrote:
> > Besides these two, I would like to continue the discussion on PR #402[3];
> > it suggests adding a flag to Oracle's DATABASE_OPTIONS, to control how
> > it returns explicit expressions from raw sql ("select 1.5 from ...").
> > The current backend (also after inclusion of PR #393) returns a python
> > Decimal, which is the Right Thing(tm) to do for Oracle, but breaks
> > cross-database compatibility (Decimals don't mix well with floats).
> >
[...]
>
> For the compatibility issue: both MySQL and PostgreSQL return Decimal
> for "select 1.5". SQLite returns float. If you want to write cross-db
> compliant raw SQL you have to deal with leaky abstractions.
>
Indeed they do. I was under the impression that it's only Oracle that does
(the other backends I usually "cross" to are Sqlite and the 3rd-party SQL
Server via pyodbc, and both return float). This makes my original motivation
completely misguided – I was thinking that people will be writing apps and not
run into the issue, because so few (at least relatively) use Oracle; that the
only people who would expect a Decimal in this situation would be already
working with Oracle, and find out about the problem soon enough. I was wrong.
So I agree with Anssi, and I closed PR #402.
Which still leaves two issues -- PR #393 (faster processign of numbers; I
think I forgot to mention earlier -- it is just some fixes on work by Ian
Kelly), and PR #411 (named parameters).
Per Jani's PR#650 (which I just went to review and found already accepted), I
note that the fix in #393 requires cx_Oracle 5.0.1; if it is accepted, the
check for cx_Oracle major version >=5 can be removed (the requirement change
comes from Ian's modifications, so it is apparently acceptable at least to one
core developer).
Thanks for your attention,
Shai.
--
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, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Oracle testing bug (was Re: Oracle testing issue, looks like bug: Separate connections to same DB)
On Thursday 03 January 2013, Jani Tiainen wrote:
> 31.12.2012 14:18, Shai Berger kirjoitti:
> > On Sunday 30 December 2012 21:54:52 Anssi Kääriäinen wrote:
> >> Seems like you are correct [...]. Please open a bug.
> >
> > For anyone interested that isn't on the new-bugs list, it's
> > https://code.djangoproject.com/ticket/19542
> >
> > For anyone else: my apologies for the noise.
> >
> > Shai.
>
> Can you please setup simple testcase to ease bugfixing?
(sorry about the delay in responding to this -- mis-managed mail)
The issue here is mostly to do with settings; thus, no testcase could be added
to the Django test suite. There are similar comments from Russel Keith-Magee
quoted on the old bug #14415.
I couldn't reasonably provide a working settings file for Oracle; for debugging
this, you just need to have a file with two connections, and have one marked as
a test mirror, i.e.
DATABASES = {
'default' : {
... whatever
},
'other' : {
... whatever
'TEST_MIRROR' = 'default'
}
}
Test code for this should look like (untested):
from django.contrib.auth.models import Group
class MirrorTest(TransactionTestCase):
def test_method():
gname='unique_and_unnatural'
g1 = Group.objects.create(name=gname) # uses default
transaction.commit(using='default')
g2 = Group.objects.all().using('other').get(name=gname)
self.assertEqual(g1,g2)
The test should verify that 'default' and 'other' are indeed the same db.
Hope this helps,
Shai.
--
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, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: A.objects.getdefault
On 10 tammi, 09:27, Wim Feijen wrote:
> Hi,
>
> Ticket 19326 has been marked as ready for check-in for some time. Can
> some-one have a look at it?
>
> https://code.djangoproject.com/ticket/19326
>
> Thanks,
>
> Wim
I did some more polish to the patch. There is now also .last() method,
and if there is no ordering in the queryset, then it will be
automatically ordered by the primary key.
I didn't commit the patch yet, as I wonder if there will be confusion
about .latest(by_field), .last(filter_args). earliest(by_field)
and .first(filter_args)?
Currently, the usage is this:
a =
Article.objects.order_by('headline').first(pub_date__year=2005)
which will return first article by headline if any found or None if no
match. .last() will just change the ordering by first
calling .reverse() on the qs.
The patch is 100% ready for commit as far as I am concerned (cursory
check of the changes doesn't hurt, of course). So, if one of the BDFLs
sees the API as fine just go and commit the patch.
Patch available from https://github.com/akaariai/django/compare/ticket_19326.
- Anssi
--
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, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
