My thoughts about this:
---
#7672 introduced a new lookup type for weekdays that was committed in
[9818]. The problem are that values that it uses. There already was
some discussion about the values but they eventually settled on
Sunday=1 and Saturday=6. Imho this is not the best decision. Of course
it is obvious that they ended up with these values because that's what
the databases are using mostly but there are problems when used with
e.g. Python internals. Python always starts with Monday being the
first day of the week whether you use weekday() (Monday=0) or
isoweekday() (Monday=1). The Python behaviour also conforms to
national/international standards and recommendations like ISO 8601 or
DIN 1355 where it also starts with Monday being the first day of the
week.
I looked at the code and i know that it requires some conversion and
changes for this but it would be even worse if you had to do that
conversion every time you're using that django feature. So my
suggestions is to change the behaviour to that of Python's weekday().
---
- The "external" representation of weekday is derived from the
internal use of weekday. So the abstraction is wrong because you work
with Django's objects - not with the database directly. That's no good
code. It shouldn't rely on each other or at least one should not rely
on the other.
- There is no standard for databases that says Sunday should be the
first day of the week. So what happens if there is going to be a
standard (that's likely going to be Monday as the first day of the
week - see next point)? Will the code be changed? Of course not - but
you'll need to do a conversion on both sides of the code. That makes
it clear why the previous point is so important.
- Monday as the first day currently is the de facto Standard for
nearly everything and it's getting more and more common. Beside the
databases there are only few things that implement it that way (as far
as i know).
- There are official standards (as i stated in my previous statement)
for this. And they all say that Monday is the first day of the week.
Most of the time it's better to rely on official rather than de facto
standards (that, in fact, are only used by a few databases).
- You always have to make a conversion when you work with it (as shown
in your example). Of course that conversion is trivial (as you showed
us) but it's something you have to do every time! That's no good code
either. Recurring code like this should go inside the implementation
(Django) and does not belong in the user's code (to take the
complexity and unnecessary work out of user's code).
---
I think that this choice is not good in anyway as i stated above. Any
suggestions or other opinions? If you have a different view on things
please tell me why.
On Thu, Mar 5, 2009 at 7:13 PM, Semmel <Florian.Sen...@web.de> wrote:
> Hi fellow developers.
> I think that the choice for Sunday being the first day of the week is > an obvious but really bad choice.
> View my ticket here: http://code.djangoproject.com/ticket/10345 ... > I think that this choice is not good in anyway as i stated above. Any > suggestions or other opinions? If you have a different view on things > please tell me why.
I agree with the Karen's comment when she closed your ticket wontfix. There is no absolute answer to this question; no matter what value you choose, there will be inconveniences. The conversion - if it is required - isn't an expensive or difficult one. You insist that 'standards' are converging on Monday as the start of the week, but you don't actually cite any of these "standards". In fact, to the contrary - the APIs surveyed in #7672 show Sunday=1 is the only option available to every database backend and Python, and in many cases, both interpretations are possible.
I don't see any advantage in changing to a different starting day at this point.
On 5 Mrz., 12:24, Russell Keith-Magee <freakboy3...@gmail.com> wrote:
> I agree with the Karen's comment when she closed your ticket wontfix.
> There is no absolute answer to this question; no matter what value you
> choose, there will be inconveniences. The conversion - if it is
> required - isn't an expensive or difficult one. You insist that
> 'standards' are converging on Monday as the start of the week, but you
> don't actually cite any of these "standards". In fact, to the contrary
> - the APIs surveyed in #7672 show Sunday=1 is the only option
> available to every database backend and Python, and in many cases,
> both interpretations are possible.
> I don't see any advantage in changing to a different starting day at this point.
Yes, there always will be inconveniences. That's not the point. The
question is not if you should choose one over the other but instead if
you should use standards or not. The databases are mostly the same -
true. But they don't follow any standards. And there are standards - i
already cited them in the ticket.
For example there's ISO 8601 (http://en.wikipedia.org/wiki/ ISO_8601#Week_dates) which says: "[D] is the weekday number, from 1
through 7, beginning with Monday and ending with Sunday.". The first
edition of ISO 8601 was from 1988 so it's been around for some time
and it's widely adopted throughout the world. That's - of course -
because it's the International Organization for Standardization. Then
for example there is DIN 1355 in germany which says exactly the same
(and it has been around since 1943) and a few years ago has been
replaced by the ISO standard.
I think there are two question that are most important.
1. How many people need to do a conversion when working with the
current weekday implementation? Maybe we should go for the value most
of the people need / would expect. Imho that would be the values that
python uses (since we are using Django in Python) and there monday is
indeed the first day of the week. What's the point of having a program
written in python when you always have to do some stupid conversion
anyway?
2. Could this become a problem in the future? Maybe yes, maybe no. You
can't say for sure. But you can reduce the risk of getting a problem
in the future if you just try to be consistent. Yeah, i know -
consistent to what? Of course consistent to python - not the database.
If you choose the same behaviour as used by python you need to do the
conversion from the database only once! Right now you have to it every
time you have to work with it! Of course - not a big deal, but that's
just no good code. Why do something several times and make it more
complex when you have the chance to do it once and take out
unnecessary lines out of the users code.
> On Thu, Mar 5, 2009 at 7:13 PM, Semmel <Florian.Sen...@web.de> wrote:
>> Hi fellow developers.
>> I think that the choice for Sunday being the first day of the week is >> an obvious but really bad choice.
>> View my ticket here: http://code.djangoproject.com/ticket/10345 > ... >> I think that this choice is not good in anyway as i stated above. Any >> suggestions or other opinions? If you have a different view on things >> please tell me why.
> I agree with the Karen's comment when she closed your ticket wontfix. > There is no absolute answer to this question; no matter what value you > choose, there will be inconveniences. The conversion - if it is > required - isn't an expensive or difficult one. You insist that > 'standards' are converging on Monday as the start of the week, but you > don't actually cite any of these "standards".
The standard is ISO 8601 which is also implemented in several national and institutional standards [1] -- including EU, Japan, Canada, Australia and the US.
> In fact, to the contrary > - the APIs surveyed in #7672 show Sunday=1 is the only option > available to every database backend and Python, and in many cases, > both interpretations are possible.
Excuse my ignorance, but if both cases are supported, why choosing the option with less use worldwide?
I wonder if it is not better to hang this issue as another bullet-point on the I18N ticket[1], like Oracle seems[2] to do.
To prevent repetitions of %7+1 code like the example given in Semmel's ticket[3], I think a cleaner approach would be to let the week_day filter take a date parameter as an alternative to int (it would then have the sense of "same week-day as"). This is a little like the license to use either keys or objects when filtering by foreign keys.
On Fri, Mar 6, 2009 at 12:26 AM, Jannis Leidel <jan...@leidel.info> wrote:
> Am 05.03.2009 um 12:24 schrieb Russell Keith-Magee:
>> On Thu, Mar 5, 2009 at 7:13 PM, Semmel <Florian.Sen...@web.de> wrote:
>>> Hi fellow developers.
>>> I think that the choice for Sunday being the first day of the week is >>> an obvious but really bad choice.
>>> View my ticket here: http://code.djangoproject.com/ticket/10345 >> ... >>> I think that this choice is not good in anyway as i stated above. Any >>> suggestions or other opinions? If you have a different view on things >>> please tell me why.
>> I agree with the Karen's comment when she closed your ticket wontfix. >> There is no absolute answer to this question; no matter what value you >> choose, there will be inconveniences. The conversion - if it is >> required - isn't an expensive or difficult one. You insist that >> 'standards' are converging on Monday as the start of the week, but you >> don't actually cite any of these "standards".
> The standard is ISO 8601 which is also implemented in several national > and institutional standards [1] -- including EU, Japan, Canada, > Australia and the US.
I missed Semmel's original reference to ISO8601.
>> In fact, to the contrary >> - the APIs surveyed in #7672 show Sunday=1 is the only option >> available to every database backend and Python, and in many cases, >> both interpretations are possible.
> Excuse my ignorance, but if both cases are supported, why choosing the > option with less use worldwide?
Both options are supported _in many cases_. Not _all_ cases. The Sunday=1 case is supported by all the backends.
Semmel and yourself both hang your arguments on the claim that Monday as the start of the week is the "most supported" option, or the "most common" option. I simply don't see any evidence that this is the case. ISO8601 may well define Monday as the first day of the week, but that's hardly the last word in the matter. Python itself offers two methods for determining weekday (weekday() and isoweekday()). Common usage (in Australia, at least) is hardly universal in nominating Monday as the first day of the week.
However, for me, this is almost completely a bikeshed discussion. I responded because I noticed the original reopen of the ticket, and I didn't want Semmel's message to go completely unanswered. Karen made a decision. Her decision works as designed, and it reflects the options commonly available to database backends. Beyond that, I can't say I really care that much - as Karen and I have both said, no matter what decision is made, somebody isn't going to be happy, but the good news is that the calculation required to rectify results isn't that hard.
Would it be possible to use cron's weekday numbering? Would that make
anyone happy?
0-7, with both 0 and 7 representing Sunday. That would at least avoid
the %7 part of the workaround (from the user's perspective, anyway).
The "Monday as first day" camp could use 1-7 for their week numbering,
and the "Sunday as first day" could use a 0-indexed week (0-6).
Sheesh, this is starting to sound like a religious war.
I think Karen made the right call here, but if there's a solution that
could make more people happy, it's worth being considered. After all,
once 1.1 goes out, we're stuck with it.
Russell Keith-Magee wrote: > Semmel and yourself both hang your arguments on the claim that Monday > as the start of the week is the "most supported" option, or the "most > common" option. I simply don't see any evidence that this is the case.
I was always under an impression that Sunday is considered first day of week only in US. Now Wikipedia (though not the English version) says it's also the case for Canada and Israel. But it's still a minority. What about Australia, Russell?
Just my two cents. There is at least one other part of the framework
which considers Sunday as the first day:
django.utils.dateformat.DateFormat (and hence some template tags).
Personally i find it annoying but at least this behaviour is
consistent over the framework and that's good.
> Russell Keith-Magee wrote: >> Semmel and yourself both hang your arguments on the claim that Monday >> as the start of the week is the "most supported" option, or the "most >> common" option. I simply don't see any evidence that this is the >> case.
> I was always under an impression that Sunday is considered first day > of > week only in US. Now Wikipedia (though not the English version) says > it's also the case for Canada and Israel. But it's still a minority. > What about Australia, Russell?
Like all interesting questions, the answer is "it depends" :-)
Printed wall calendars almost universally put Sunday as the first box in the week. However, a quick straw poll of the people in my office gave opinions 50/50 each way, but everyone agreed that either was just as valid and common.
In my bike shed (and cron's), Sunday is 0 AND 7, which seems nice.
Then your week can starting with Sunday as 0-6 or Monday as 1-7.
Oh, I see that Bob Thomas already suggested this. Isn't it a moot
point, though? Isn't it considered a backwards incompatible change
even if made before 1.1? Or is backwards compatibility only promised
between release versions, so trunk can have a tentative API for new
features until the next official release?
> I was always under an impression that Sunday is considered first day of > week only in US. Now Wikipedia (though not the English version) says > it's also the case for Canada and Israel. But it's still a minority.
In Israel, as well as most Arab countries, Sunday is a business day, so Monday as first day doesn't even make sense.
(My earlier suggestion notwithstanding, I support the core developers' position that it doesn't _really_ matter. Due diligence: I'm in Israel, so the current decision happens to be convenient, too).
Although in Brazil Sunday is not considered a business day, it's considered
the first day of the week. I believe the same occurrs in most Latin America.
I cannot see where a such decision can influence much in a development
environment. Most programming languanges/frameworks/APIs/whatever consider
Sunday as the first day. It would make sense to maintain certain
consistence, in this case.
On Sat, Mar 7, 2009 at 6:39 AM, Shai Berger <s...@platonix.com> wrote:
> On Friday 06 March 2009, Ivan Sagalaev wrote:
> > I was always under an impression that Sunday is considered first day of
> > week only in US. Now Wikipedia (though not the English version) says
> > it's also the case for Canada and Israel. But it's still a minority.
> In Israel, as well as most Arab countries, Sunday is a business day, so
> Monday
> as first day doesn't even make sense.
> (My earlier suggestion notwithstanding, I support the core developers'
> position that it doesn't _really_ matter. Due diligence: I'm in Israel, so
> the current decision happens to be convenient, too).
On Sat, Mar 7, 2009 at 6:30 PM, Tai Lee <real.hu...@mrmachine.net> wrote:
> In my bike shed (and cron's), Sunday is 0 AND 7, which seems nice. > Then your week can starting with Sunday as 0-6 or Monday as 1-7.
> Oh, I see that Bob Thomas already suggested this. Isn't it a moot > point, though? Isn't it considered a backwards incompatible change > even if made before 1.1? Or is backwards compatibility only promised > between release versions, so trunk can have a tentative API for new > features until the next official release?
We will always strive to avoid backwards incompatibilities, but the official guarantee is based on released versions. So - strictly, we have a window of opportunity where we could change this, but we're not going to make such changes without a very good reason, such as a clearly flawed API.
On Mar 6, 7:24 am, Russell Keith-Magee <freakboy3...@gmail.com> wrote:
> Both options are supported _in many cases_. Not _all_ cases. The
> Sunday=1 case is supported by all the backends.
Imho that's no real argument. Yeah, i can understand why this was
choosen in the first way (because it's somehow easier to implement)
but there's one thing we should not forget. The case where Monday is
the first day of the week is based on "real" standards (things you can
read, print out, refer to) whereas Sunday as the first day of the week
isn't anything even near a standard - it just evolved over time. So
from a developers point of view it's better to settle on something
that is well defined.
> Semmel and yourself both hang your arguments on the claim that Monday
> as the start of the week is the "most supported" option, or the "most
> common" option. I simply don't see any evidence that this is the case.
> ISO8601 may well define Monday as the first day of the week, but
> that's hardly the last word in the matter. Python itself offers two
> methods for determining weekday (weekday() and isoweekday()). Common
> usage (in Australia, at least) is hardly universal in nominating
> Monday as the first day of the week.
Well maybe it's not the "most supported" or "most common" option, we
don't know that for certain. But it's the option that most of
developers can use without(!) a conversion so i think we should go for
that.
By the way:
Has anyone even noticed that in Python both weekday() and isoweekday()
use Monday as the first day of the week??? So i think there should be
no discussion about this anyway. Just use Python's standards and we're
set.
> However, for me, this is almost completely a bikeshed discussion. I
> responded because I noticed the original reopen of the ticket, and I
> didn't want Semmel's message to go completely unanswered. Karen made a
> decision. Her decision works as designed, and it reflects the options
> commonly available to database backends. Beyond that, I can't say I
> really care that much - as Karen and I have both said, no matter what
> decision is made, somebody isn't going to be happy, but the good news
> is that the calculation required to rectify results isn't that hard.
Just one question: WHY should it reflect the options available for the
database backends? Since you want to work with that stuff on Python's
side it should reflect the options given by Python. So that makes
absolutely no sense!
That's no discussion about wether one will be unhappy or not - it's
just against common sense. That's why i find that decision so weird.
I respect Karen's decision but it don't think that all points where
thought through.
Just to note: I am pushing this discussion as we will be stuck with it
when 1.1 is released and i don't want this to happen with an imho
flawed implementation.
On Mon, 2009-03-09 at 03:20 -0700, Semmel wrote: > On Mar 6, 7:24 am, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > > Both options are supported _in many cases_. Not _all_ cases. The > > Sunday=1 case is supported by all the backends.
> Imho that's no real argument. Yeah, i can understand why this was > choosen in the first way (because it's somehow easier to implement) > but there's one thing we should not forget. The case where Monday is > the first day of the week is based on "real" standards (things you can > read, print out, refer to)
So what??? Nobody actually does print out those standards and read them and it takes approximately 3 seconds, if you think very slowly, to be able to handle Sunday as the first day of the week if you were previously handling Monday.
There are some libraries that expect Monday to be the first day of the week and others that expect to it to be Sunday. You'll never be able to close your eyes and always use one value, so, in that respect, it doesn't matter what we choose.
> whereas Sunday as the first day of the week > isn't anything even near a standard - it just evolved over time. So > from a developers point of view it's better to settle on something > that is well defined.
Sunday is very well defined. There's absolutely no ambiguity over which day of the week Sunday is. There is, however, quite genuine ambiguity over which day of the week is "expected" to be the first day of the week as even a casual perusal of this thread would show.
A sentence saying "the first day of the week is Sunday" in the docs will not be misunderstood, believe me.
[...]
> Well maybe it's not the "most supported" or "most common" option, we > don't know that for certain. But it's the option that most of > developers can use without(!) a conversion so i think we should go for > that.
Basic logic: If it's not most supported or most common, then that assertion is pretty much false by definition. The choices are basically between Monday and Sunday, not Monday and Thursday or something. So if Monday isn't the most common, Sunday will be.
> By the way: > Has anyone even noticed that in Python both weekday() and isoweekday() > use Monday as the first day of the week???
Perhaps you could check ths sarcasm at the door? Everybody who's responded in this thread has exhibited intelligence towards you.
> So i think there should be > no discussion about this anyway. Just use Python's standards and we're > set.
Or we could just use the value that matches what a number of our databases (and a number of other programs) use and we're also set, since it works well with all other code using those databases.
> > However, for me, this is almost completely a bikeshed discussion. I > > responded because I noticed the original reopen of the ticket, and I > > didn't want Semmel's message to go completely unanswered. Karen made a > > decision. Her decision works as designed, and it reflects the options > > commonly available to database backends. Beyond that, I can't say I > > really care that much - as Karen and I have both said, no matter what > > decision is made, somebody isn't going to be happy, but the good news > > is that the calculation required to rectify results isn't that hard.
> Just one question: WHY should it reflect the options available for the > database backends?
You're simply answering a question with a question, in effect. It's an essentially arbitrary decision, since there are arguments both ways. Yes, you've added your own weights to the arguments, but at least acknowledge that two sides exist. When it comes down to "why one or the other" between two roughly equal choices, you can always ask "why not the other way" and the answer is because we chose the way we did. You can see from the history of this code that the decision was made intentionally.
> Since you want to work with that stuff on Python's > side it should reflect the options given by Python. So that makes > absolutely no sense!
Incorrect, as noted above and elsewhere in this thread.
> That's no discussion about wether one will be unhappy or not - it's > just against common sense.
No, it isn't. Please stop characterising people disagreeing with you as being against "common sense" and "weird". Logical arguments have been used throughout; you happen not to agree with them, but that doesn't make the alternative side nonsensical.
> That's why i find that decision so weird. > I respect Karen's decision but it don't think that all points where > thought through.
No. All of the points were thought through. it's just coming down to people not agreeing with you that it's worth changing. There's a huge difference. There is really no technical difference between which choice we make (since our code doesn't run on top of paper standards that most programmers would not even be able to name).
> Just to note: I am pushing this discussion as we will be stuck with it > when 1.1 is released and i don't want this to happen with an imho > flawed implementation.
Deal with it, frankly. It's not flawed, it's a choice. You've said that's your opinion and everybody respects that. It just isn't enough of a justificaiton to change things.
> On Mon, 2009-03-09 at 03:20 -0700, Semmel wrote:
> > On Mar 6, 7:24 am, Russell Keith-Magee <freakboy3...@gmail.com> wrote:
> > > Both options are supported _in many cases_. Not _all_ cases. The
> > > Sunday=1 case is supported by all the backends.
> > Imho that's no real argument. Yeah, i can understand why this was
> > choosen in the first way (because it's somehow easier to implement)
> > but there's one thing we should not forget. The case where Monday is
> > the first day of the week is based on "real" standards (things you can
> > read, print out, refer to)
> So what??? Nobody actually does print out those standards and read them
> and it takes approximately 3 seconds, if you think very slowly, to be
> able to handle Sunday as the first day of the week if you were
> previously handling Monday.
> There are some libraries that expect Monday to be the first day of the
> week and others that expect to it to be Sunday. You'll never be able to
> close your eyes and always use one value, so, in that respect, it
> doesn't matter what we choose.
> > whereas Sunday as the first day of the week
> > isn't anything even near a standard - it just evolved over time. So
> > from a developers point of view it's better to settle on something
> > that is well defined.
> Sunday is very well defined. There's absolutely no ambiguity over which
> day of the week Sunday is. There is, however, quite genuine ambiguity
> over which day of the week is "expected" to be the first day of the week
> as even a casual perusal of this thread would show.
> A sentence saying "the first day of the week is Sunday" in the docs will
> not be misunderstood, believe me.
> [...]
> > Well maybe it's not the "most supported" or "most common" option, we
> > don't know that for certain. But it's the option that most of
> > developers can use without(!) a conversion so i think we should go for
> > that.
> Basic logic: If it's not most supported or most common, then that
> assertion is pretty much false by definition. The choices are basically
> between Monday and Sunday, not Monday and Thursday or something. So if
> Monday isn't the most common, Sunday will be.
> > By the way:
> > Has anyone even noticed that in Python both weekday() and isoweekday()
> > use Monday as the first day of the week???
> Perhaps you could check ths sarcasm at the door? Everybody who's
> responded in this thread has exhibited intelligence towards you.
> > So i think there should be
> > no discussion about this anyway. Just use Python's standards and we're
> > set.
> Or we could just use the value that matches what a number of our
> databases (and a number of other programs) use and we're also set, since
> it works well with all other code using those databases.
> > > However, for me, this is almost completely a bikeshed discussion. I
> > > responded because I noticed the original reopen of the ticket, and I
> > > didn't want Semmel's message to go completely unanswered. Karen made a
> > > decision. Her decision works as designed, and it reflects the options
> > > commonly available to database backends. Beyond that, I can't say I
> > > really care that much - as Karen and I have both said, no matter what
> > > decision is made, somebody isn't going to be happy, but the good news
> > > is that the calculation required to rectify results isn't that hard.
> > Just one question: WHY should it reflect the options available for the
> > database backends?
> You're simply answering a question with a question, in effect. It's an
> essentially arbitrary decision, since there are arguments both ways.
> Yes, you've added your own weights to the arguments, but at least
> acknowledge that two sides exist. When it comes down to "why one or the
> other" between two roughly equal choices, you can always ask "why not
> the other way" and the answer is because we chose the way we did. You
> can see from the history of this code that the decision was made
> intentionally.
> > Since you want to work with that stuff on Python's
> > side it should reflect the options given by Python. So that makes
> > absolutely no sense!
> Incorrect, as noted above and elsewhere in this thread.
> > That's no discussion about wether one will be unhappy or not - it's
> > just against common sense.
> No, it isn't. Please stop characterising people disagreeing with you as
> being against "common sense" and "weird". Logical arguments have been
> used throughout; you happen not to agree with them, but that doesn't
> make the alternative side nonsensical.
> > That's why i find that decision so weird.
> > I respect Karen's decision but it don't think that all points where
> > thought through.
> No. All of the points were thought through. it's just coming down to
> people not agreeing with you that it's worth changing. There's a huge
> difference. There is really no technical difference between which choice
> we make (since our code doesn't run on top of paper standards that most
> programmers would not even be able to name).
> > Just to note: I am pushing this discussion as we will be stuck with it
> > when 1.1 is released and i don't want this to happen with an imho
> > flawed implementation.
> Deal with it, frankly. It's not flawed, it's a choice. You've said
> that's your opinion and everybody respects that. It just isn't enough of
> a justificaiton to change things.
> Let's move on.
> Malcolm
Personally if someone really has this much of an issue make up a bunch of
constants and use them in your code, then you don't even have to think about
the number:
On Mar 9, 11:48 am, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
> This is getting ridiculous.
This seems to move towards some kind of religious war (this is
ridiculous by its very nature) and I surely could live we either
decision . But I would expect django as a python webframework to mimic
the python implementation which is also used in utils/dates.py.
On Mon, Mar 9, 2009 at 11:11 AM, Casper Star <i...@einsamermusiker.de>wrote:
> On Mar 9, 11:48 am, Malcolm Tredinnick <malc...@pointy-stick.com> > wrote: > > This is getting ridiculous.
> This seems to move towards some kind of religious war (this is > ridiculous by its very nature) and I surely could live we either > decision . But I would expect django as a python webframework to mimic > the python implementation which is also used in utils/dates.py.
If you are referring to the WEEKDAYS, etc, dictionaries in utils/dates.py they are used internally to look up the values returned from Python's weekday() and transform them to strings so naturally they have to match the Python weekday() return values. As far as I can tell they aren't used for anything else.
I've been quiet on this thread primarily because I haven't had much time for Django stuff in the last week+, secondarily because I wanted to hear what others thought, and finally because I already gave my opinion in the ticket. For the record here, though, I'll say I'm not overly attached to the current implementation, and I wouldn't stand in the way if some other committer wanted to change it (I haven' t heard that from anyone, though). It wasn't actually my choice, it was what was in the ticket when I went to look at it to commit it, it looked reasonable to me given the choices surveyed, and I saw no reason to change it.
I still see no reason to change it. I, personally, haven't noticed any convergence on a standard starting weekday of Monday in everyday life -- all my wall calendars (3) start with Sunday, though my desk calendar starts with Monday. Granted it's a bit of a nuisance that you have to adjust the output of Python's isoweekday() to feed into this new lookup, but it isn't like all uses of this new lookup are going to be starting off with a input datetime object that you want to match the weekday of. I actually expect it'll be more common to be feeding in results from a choice field or somesuch where assignment of choice values to user-visible strings is done manually by the programmer...no Python datetimes involved.
Summary: I still think no matter what was chosen here someone would be unhappy, and I still see no compelling reason to switch from what's already implemented.
On Mar 9, 11:48 am, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
> So what??? Nobody actually does print out those standards and read them
> and it takes approximately 3 seconds, if you think very slowly, to be
> able to handle Sunday as the first day of the week if you were
> previously handling Monday.
True, i don't print them out but i'm always glad if i can refer to
one. You can't imagine in what kind of hell you can get without
standards, and that's the reason i write here.
> There are some libraries that expect Monday to be the first day of the
> week and others that expect to it to be Sunday. You'll never be able to
> close your eyes and always use one value, so, in that respect, it
> doesn't matter what we choose.
100% right, from the practical point of view.
> Sunday is very well defined. There's absolutely no ambiguity over which
> day of the week Sunday is. There is, however, quite genuine ambiguity
> over which day of the week is "expected" to be the first day of the week
> as even a casual perusal of this thread would show.
> A sentence saying "the first day of the week is Sunday" in the docs will
> not be misunderstood, believe me.
Hmm. True.
But that's one of those points where somebody will cry out loud
saying: "week_day does not what i expect it to do" (if he expects
Monday as first day). And then you can refer to the docs and say "read
there" and he will either be like "alright" or "why is Sunday the
first day?".
I personally find it very annoying when i have to work with different
week_day implementations from platform to platform and i'm always
happy if it just says "this thing here works after ISO XYZ" and i
don't have to read any further because i know what it's going to do. I
mean, that's the whole point of standards, read it once and the use it
everywhere.
> > Well maybe it's not the "most supported" or "most common" option, we
> > don't know that for certain. But it's the option that most of
> > developers can use without(!) a conversion so i think we should go for
> > that.
> Basic logic: If it's not most supported or most common, then that
> assertion is pretty much false by definition. The choices are basically
> between Monday and Sunday, not Monday and Thursday or something. So if
> Monday isn't the most common, Sunday will be.
Alright, sorry. It _is_ the most used value. Python and nearly all
modules _always_ use Monday as the first they of the week. Beside that
you're right.
> > By the way:
> > Has anyone even noticed that in Python both weekday() and isoweekday()
> > use Monday as the first day of the week???
> Perhaps you could check ths sarcasm at the door? Everybody who's
> responded in this thread has exhibited intelligence towards you.
Sorry, i didn't want to be rude. It just have the feeling that ...
well, i really don't know.
I used so many national and international standards over the year and
i always find it great if i have something i can rely upon. And it
would just annoy me to see this feature going against the official
international standard. Maybe i shouldn't spend so much energy on
that. :/
> > So i think there should be
> > no discussion about this anyway. Just use Python's standards and we're
> > set.
> Or we could just use the value that matches what a number of our
> databases (and a number of other programs) use and we're also set, since
> it works well with all other code using those databases.
BUT creates more code on the user side. That's the whole point of a
framework - keep the complex and repeating stuff inside.
> > Just one question: WHY should it reflect the options available for the
> > database backends?
> You're simply answering a question with a question, in effect. It's an
> essentially arbitrary decision, since there are arguments both ways.
> Yes, you've added your own weights to the arguments, but at least
> acknowledge that two sides exist. When it comes down to "why one or the
> other" between two roughly equal choices, you can always ask "why not
> the other way" and the answer is because we chose the way we did. You
> can see from the history of this code that the decision was made
> intentionally.
I see that it was made intentionally and that's basically okay for me.
And yes i acknowledge that there are arguments both ways.
And of course someone could always ask "why not the other" way. And
that's exactly the situation where i'd like to say "we did it that way
because there are more arguments for this that for the other". And
that's what's the case - one reason (because the databases are using
it) for the "Sunday-side" and multiple reasons for the "Monday"-side.
> > Since you want to work with that stuff on Python's
> > side it should reflect the options given by Python. So that makes
> > absolutely no sense!
> Incorrect, as noted above and elsewhere in this thread.
Maybe i was a bit harsh as it partially makes sense but it still don't
see why it is incorrect.
> > That's no discussion about wether one will be unhappy or not - it's
> > just against common sense.
> No, it isn't. Please stop characterising people disagreeing with you as
> being against "common sense" and "weird". Logical arguments have been
> used throughout; you happen not to agree with them, but that doesn't
> make the alternative side nonsensical.
True. Sorry for that.
> > That's why i find that decision so weird.
> > I respect Karen's decision but it don't think that all points where
> > thought through.
> No. All of the points were thought through. it's just coming down to
> people not agreeing with you that it's worth changing. There's a huge
> difference. There is really no technical difference between which choice
> we make (since our code doesn't run on top of paper standards that most
> programmers would not even be able to name).
No, they weren't because some of them were unknown at the time of
Karen's decision.
But it totally agree with you that the whole point is if we should
change it or not - and i understand that. A decision has been made and
that's how it is now.
"since our code doesn't run on top of paper standards that most
programmers would not even be able to name"
Really? Why is that? Personally i think that's sad because that is
exactly the reason why many things in the it world got so wrong.
Hungarian notation or HTML/CSS rendering. That all did happen because
nobody did read the standards ... :(
Well, that's another story.
> > Just to note: I am pushing this discussion as we will be stuck with it
> > when 1.1 is released and i don't want this to happen with an imho
> > flawed implementation.
> Deal with it, frankly. It's not flawed, it's a choice. You've said
> that's your opinion and everybody respects that. It just isn't enough of
> a justificaiton to change things.
Alright, i respect that. Just out of interest - what kind of
"argument" would justify this?
> Let's move on.
> Malcolm
I didn't want to bloat all this stuff so heavily but as you've already
noticed i can't stand things going against official standards.
But the decision has been made and although i don't agree with it i
will accept that.
On Mar 9, 8:13 pm, Karen Tracey <kmtra...@gmail.com> wrote:
> I still see no reason to change it. I, personally, haven't noticed any
> convergence on a standard starting weekday of Monday in everyday life -- all
> my wall calendars (3) start with Sunday, though my desk calendar starts with
> Monday. Granted it's a bit of a nuisance that you have to adjust the output
> of Python's isoweekday() to feed into this new lookup, but it isn't like all
> uses of this new lookup are going to be starting off with a input datetime
> object that you want to match the weekday of. I actually expect it'll be
> more common to be feeding in results from a choice field or somesuch where
> assignment of choice values to user-visible strings is done manually by the
> programmer...no Python datetimes involved.
Well that may be an argument. Maybe i won't have any problems with
this at all. :)
On a side note: I haven't noticed any problems with that in everyday
life yet. BUT i had exactly this problem a few times before and i
always found it very cumbersome to convert the values - mostly between
the databases (that have no "standard") and my software and components
that mostly follow the ISO standard. So that's my personal background
for this matter and that's why i still think it's not the best choice.
But it's a choice and the workaround is not that hard so i'll leave it
"as is".
|
