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. Regards, Semmel --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
