I have an application which runs on 2.4.4 and is known not to run on 2.4.1 or
2.5, and I'm trying to install 2.4.4 from the website.
Whenever I download and compile the 2.4.4 sources, the executable shows up as
2.4.1 which will not work for my application.
I've downloaded both the bzip and gzip v
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
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
> ./c
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) test_ope
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 w
>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 considera
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 t
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
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 read/grok
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.
>> 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(
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 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
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 t
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 ne
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:
> 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
>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.
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 PE
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 assumption
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 re
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
__
Extension
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
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
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, 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.
>
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 datetim
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 explicitl
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
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 e
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 t
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.
A
"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
__
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
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 n
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
curren
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
___
37 matches
Mail list logo
