Hi Collin,
On Wed, Mar 07, 2007 at 11:53:45PM -0600, Collin Winter wrote:
bool() and abs() aren't syntax, so I would never look in operator.
abs() is not syntax but bool() is part of every syntactic construction
that takes a truth value argument (if, while, and, ...)
A bientot,
Armin
Hi,
There was a thread some weeks ago about work on pydoc, with the
admitted aim of proposing something as an upgrade to the current
pydoc.
We had a number of suggestions, on this very list or privately, and we
looked into
having something that would not only retain the capabilities of the
On 3/11/07, Laurent Gautier [EMAIL PROTECTED] wrote:[...]
A prototype is being worked on, and I have been looking at code and/or
functionalities in pydoc, epydoc, pydoctor, and ipython (for the
interactive console), and there a lot of nice things in all these
efforts. The name of the game is
2007/3/11, Gustavo Carneiro [EMAIL PROTECTED]:
On 3/11/07, Laurent Gautier [EMAIL PROTECTED] wrote:
[...]
A prototype is being worked on, and I have been looking at code and/or
functionalities in pydoc, epydoc, pydoctor, and ipython (for the
interactive console), and there a lot of nice
Gustavo Carneiro [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| Most importantly, we also need the reserve: ability to attach external
| documentation to modules/packages without increasing their size.
Perhaps use .pd for the extension
tjr
At 5:45 PM +1300 3/11/07, Greg Ewing wrote:
Jon Ribbens wrote:
What do you feel next Tuesday plus 12 hours means? ;-)
I would say it's meaningless. My feeling is that subtracting
two dates should give an integer number of days, and that is
all you should be allowed to add to a date.
Apple's
On Sun, Mar 11, 2007 at 11:02:39AM -0500, Tony Nelson wrote:
Apple's old MacOS had a very flexible LongDateRecord and date utilities.
Nearly anything one could do to a date had a useful meaning. Perhaps
Python should be different, but I've found Apple's date calculations and
date parsing to
On 3/10/07, Jon Ribbens [EMAIL PROTECTED] wrote:
I see you snipped without response my request to back up your claim
that assuming that a date() is a datetime() with a time of midnight
will clearly break that logic.
Am I to assume you cannot back it up?
I was trying to minimize the extent of
Jon Ribbens schrieb:
I see you snipped without response my request to back up your claim
that assuming that a date() is a datetime() with a time of midnight
will clearly break that logic.
I've another idea. Date and datetime objects are compared by date. The
date object for a given date is
Please forgive me if this has already been discussed -- I only
recently started paying any attention to this list.
Many versions of python include new standard library modules that
could (or often do already) work fine with previous versions. Some of
the modules are brand-new, written explicitly
On 3/11/07, Christian Heimes [EMAIL PROTECTED] wrote:
Jon Ribbens schrieb:
I see you snipped without response my request to back up your claim
that assuming that a date() is a datetime() with a time of midnight
will clearly break that logic.
I've another idea. Date and datetime objects
On 3/11/07, Steven Bethard [EMAIL PROTECTED] wrote:
On 3/11/07, Christian Heimes [EMAIL PROTECTED] wrote:
I've another idea. Date and datetime objects are compared by date. The
date object for a given date is always smaller than the datetime for the
same day - even for midnight.
I really
On 3/11/07, Patrick Maupin [EMAIL PROTECTED] wrote:
Please forgive me if this has already been discussed -- I only
recently started paying any attention to this list.
Many versions of python include new standard library modules that
could (or often do already) work fine with previous
On 3/11/07, BJörn Lindqvist [EMAIL PROTECTED] wrote:
I do not really understand proper temporal intervals. But I am
interested what temporal interval logic has to say about this
problem:
def get_most_recent_articles(articles, cutoff_date):
recent_articles = []
for article in
Jon Ribbens wrote:
Robert Brewer [EMAIL PROTECTED] wrote:
One solution that just occurred to me -- and that
skirts the issue of choosing an interpretation --
is that, when comparing date and datetime objects,
the datetime's .date() method is called and the
result of that call is
Steven Bethard [EMAIL PROTECTED] wrote:
I was trying to minimize the extent of this already too long thread,
assuming you could go do the reading I referred you to if you were
really interested in the answer.
There's nothing to be gained by being patronising.
I still encourage you to read
On 3/11/07, Jon Ribbens [EMAIL PROTECTED] wrote:
[snark]
It makes pragmatic assumptions about
what people mean when they use date arithmetic. They might not be the
assumptions you want, but then it's probably not the module you want.
Please find or write a package that makes the assumptions
On 11 Mar, 10:32 pm, [EMAIL PROTECTED] wrote:
If this seems useful to others, I could try to start a PEP on how the
process would work (but since I'm fairly new, it would be great if
someone could help out a bit by validating my verbiage against some of
the process requirements).
Isn't this
I wrote two versions of the dict views refactoring. One that turns
d.keys() into list(d.keys()) and d.iterkeys() into iter(d.keys()).
This one is pretty robust except if you have classes that emulate
2.x-style dicts. But it generates ugly code. So I have a
light-weight version that leaves d.keys()
On 3/11/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On 11 Mar, 10:32 pm, [EMAIL PROTECTED] wrote:
If this seems useful to others, I could try to start a PEP on how the
process would work (but since I'm fairly new, it would be great if
someone could help out a bit by validating my verbiage
Collin Winter [EMAIL PROTECTED] wrote:
Please find or write a package that makes the assumptions you want,
since datetime clearly isn't the module you want.
Datetime clearly *is* the module I want. It already makes the
assumptions I want, I just want it to make them consistently.
On 3/11/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Isn't this PEP 297?
Thanks for pointing that out. I looked for a relevant PEP, but didn't
notice this one. I think this is complementary, but (if I am reading
it correctly) it is not exactly the same. The alternate search path
is a
Patch / Bug Summary
___
Patches : 380 open (-36) / 3658 closed (+65) / 4038 total (+29)
Bugs: 965 open ( -9) / 6555 closed (+35) / 7520 total (+26)
RFE : 272 open ( +4) / 253 closed ( +2) / 525 total ( +6)
New / Reopened Patches
__
I decided it would be worthwhile to have a csv module written in Python (no
C underpinnings) for a number of reasons:
* It will probably be easier to add Unicode support to a Python version
* More people will be able to read/grok/modify/fix bugs in a Python
implementation than in
I decided it would be worthwhile to have a csv module written in Python (no
C underpinnings) for a number of reasons:
Several other people have already done this. I will forward you their
e-mail address in a separate private e-mail.
I'm far from having anything which will pass the current test
Andrew McNamara [EMAIL PROTECTED] wrote:
The point was to produce the same results as Excel. Sure, Excel probably
doesn't generate crap like this itself, but 3rd parties do, and people
complain if we don't parse it just like Excel (sigh).
The slight problem with copying Excel is that Excel
I'm far from having anything which will pass the current test suite,
but in diagnosing some of my current failures I noticed a couple test
cases which seem wrong. In the TestDialectExcel class I see these
two questionable tests:
def test_quotes_and_more(self):
John IMHO these test cases are *WRONG* and it's a worry that they
John work with the current csv module :-(
That's my take on things as well, though as Andrew pointed out, given those
invalid inputs Excel will produce those wacky outputs. I verified that on
my Mac a few minutes ago.
On 12/03/2007 1:01 PM, [EMAIL PROTECTED] wrote:
I decided it would be worthwhile to have a csv module written in Python (no
C underpinnings) for a number of reasons:
* It will probably be easier to add Unicode support to a Python version
* More people will be able to
On 12/03/2007 1:41 PM, Andrew McNamara wrote:
The point was to produce the same results as Excel. Sure, Excel probably
doesn't generate crap like this itself, but 3rd parties do, and people
complain if we don't parse it just like Excel (sigh).
Let's put a little flesh on those a's and b's:
Jon Ribbens wrote:
Steven Bethard [EMAIL PROTECTED] wrote:
We know that:
date(2006, 1, 1) *Includes* datetime(2006, 1, 1, 0, 0, 1)
Oh dear. You've fallen at the first hurdle. We do not know that.
Translated into English, this is saying The 1st of January
2006 includes the time one
IMHO these test cases are *WRONG* and it's a worry that they work with
the current csv module :-(
Those tests are not wrong - they verify that we produce the same result
as Excel when presented with those inputs, which was one of the design
goals of the module (and is an important consideration
Jerry Seutter posted patch #1678088 yesterday, which converts
test_operations over to use unittest and folds the resulting code into
test_dict. It struck me as a good idea, because a) it gets away from
output/-based tests, and b) test_operations tests certain dictionary
operations, something that
On 3/11/07, Collin Winter [EMAIL PROTECTED] wrote:
Jerry Seutter posted patch #1678088 yesterday, which converts
test_operations over to use unittest and folds the resulting code into
test_dict. It struck me as a good idea, because a) it gets away from
output/-based tests, and b)
Unless someone speaks up to save Python/fmod.c, I'll remove this file
in a few days.
Thanks Paul!
n
--
On 3/10/07, Paul Hankin [EMAIL PROTECTED] wrote:
Hi all,
Is there any need for Python/fmod.c any more? I can't see how
it can be included because there's no test for fmod in the
Laurent Gautier wrote:
- low-energy barrier for adding support for other-than-plain-text docstrings
I'd be interested in discussing this offline (I might have already
spoken to you about it before, but I don't remember who I spoke to.) I
think I've mentioned before about DocLobster, which is
36 matches
Mail list logo
