Tim Peters wrote:
>> Author: walter.doerwald
>> Date: Sat Apr 1 22:40:23 2006
>> New Revision: 43545
>>
>> Modified:
>>python/trunk/Doc/lib/libcalendar.tex
>>python/trunk/Lib/calendar.py
>> Log:
>> Make firstweekday a simple attribute instead
>> of hiding it behind a setter and a getter.
>
Tim Peters wrote:
> For gcc we _could_ solve it in the obvious way, which I guess Martin
> was hoping to avoid: change Unixish config to detect whether the
> platform C supports the "z" format modifier (I believe gcc does), and
> if so arrange to stick
>
> #define PY_FORMAT_SIZE_T "z"
It's not g
On 4/1/06, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> There are several test cases in test_trace that are commented out. We
> did this when we merged the ast-branch and promised to come back to
> them. I'm coming back to them now, but the test aren't documented
> well and the feature they test is
On Sunday 02 April 2006 14:17, Anthony Baxter wrote:
> I've created a searchbar plugin for the firefox search bar that
> allows you to search bugs.
I should clarify - it allows you to pull up a bug by bug ID, using the
www.python.org/sf/ redirector.
I've created a searchbar plugin for the firefox search bar that allows
you to search bugs. I think someone created one for the sidebar, but
this works in the searchbar at the top of the window. I gave up
trying to knit the files into the new website builder, and so it can
be found here:
htt
On 4/1/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Brett Cannon]
> > ...
> > This is just so ridiculous.
>
> Ya think ;-)?
>
> > Is there even a way to do this reasonably?
>
> Not really in C89. That's why C99 introduced the "z" printf modifier,
> and approximately a billion ;-) format macros li
[Brett Cannon]
> ...
> This is just so ridiculous.
Ya think ;-)?
> Is there even a way to do this reasonably?
Not really in C89. That's why C99 introduced the "z" printf modifier,
and approximately a billion ;-) format macros like PY_FORMAT_SIZE_T
(since there's almost nothing portably useful
On 4/1/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Brett Cannon]
> > I think these are all Tim's fault =) :
>
> No, they're Anthony's fault :-) He added this clause to pyport.h yesterday:
>
> # if SIZEOF_SIZE_T == SIZEOF_INT
> # define PY_FORMAT_SIZE_T ""
>
> and that's obviously triggeri
[Brett Cannon]
> I think these are all Tim's fault =) :
No, they're Anthony's fault :-) He added this clause to pyport.h yesterday:
# if SIZEOF_SIZE_T == SIZEOF_INT
# define PY_FORMAT_SIZE_T ""
and that's obviously triggering on your platform. He added this (at
my suggestion) to shut u
I think these are all Tim's fault =) :
Objects/object.c: In function '_Py_NegativeRefcount':
Objects/object.c:144: warning: format '%d' expects type 'int', but
argument 7 has type 'Py_ssize_t'
Objects/stringobject.c: In function 'PyString_FromFormatV':
Objects/stringobject.c:278: warning: format '
I reported some warnings I was getting for ctypes the other day and
Martin said I should report it to ctypes. I now get a warning for
sqlite on OS X 10.4 about INT32_MIN being redefined (I have stdint.h
on my machine and that macro is being redefined in
Modules/_sqlite/cursor.c instead of using th
> Author: walter.doerwald
> Date: Sat Apr 1 22:40:23 2006
> New Revision: 43545
>
> Modified:
>python/trunk/Doc/lib/libcalendar.tex
>python/trunk/Lib/calendar.py
> Log:
> Make firstweekday a simple attribute instead
> of hiding it behind a setter and a getter.
Walter, what's the purpose o
Ok, I uploaded it.
Patch no. 1462796:
https://sourceforge.net/tracker/index.php?func=detail&aid=1462796&group_id=5470&atid=305470
On 4/1/06, Aahz <[EMAIL PROTECTED]> wrote:
> On Sat, Apr 01, 2006, Noam Raphael wrote:
> >
> > I've found out that the hash value of tuples isn't saved after it's
> >
On Sat, Apr 01, 2006, Noam Raphael wrote:
>
> I've found out that the hash value of tuples isn't saved after it's
> calculated. With strings it's different: the hash value of a string is
> calculated only on the first call to hash(string), and saved in the
> structure for future use. Saving the val
Hello,
I've found out that the hash value of tuples isn't saved after it's
calculated. With strings it's different: the hash value of a string is
calculated only on the first call to hash(string), and saved in the
structure for future use. Saving the value makes dict lookup of tuples
an operation
On 4/1/06, Michael Hudson <[EMAIL PROTECTED]> wrote:
>
> I don't know if anyone runs Python under valgrind regularly though.
I do for some definition of "regularly". It would be better to setup
a cron job to truly run it regularly, perhaps once a month. It should
run on both HEAD and supported r
> Yes Gmane is subscribed.
> I checked if there is a pydev-3000 newsgroup on there server.
I found the renamed group. Prefered the original name since it sorted just
after this one in the subscribed groups list.
tjr
___
Python-Dev mailing list
Pyth
There are several test cases in test_trace that are commented out. We
did this when we merged the ast-branch and promised to come back to
them. I'm coming back to them now, but the test aren't documented
well and the feature they test isn't specified well.
The failing tests I've looked at so far
On Thu, 30 Mar 2006, Greg Ewing wrote:
> I just thought of a possible name for the
> Python package repository. We could call
> it the PIPE - Python Index of Packages
> and Extensions.
+1
John
___
Python-Dev mailing list
Python-Dev@python.org
http://m
Hi Michael,
On Sat, Apr 01, 2006 at 02:54:25PM +0100, Michael Hudson wrote:
> It's actually because somewhere in the bowels of compilation, the file
> name being compiled gets interned and test_pkg writes out some
> temporary files and imports them. If this doesn't happen on the
> trunk, did this
"Chris AtLee" <[EMAIL PROTECTED]> writes:
> On 3/28/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
>> We've made a lot of improvement with testing over the years.
>> Recently, we've gotten even more serious with the buildbot, Coverity,
>> and coverage (http://coverage.livinglogic.de). However, in or
Armin Rigo <[EMAIL PROTECTED]> writes:
> Hi Neal,
>
> On Sun, Mar 26, 2006 at 11:39:50PM -0800, Neal Norwitz wrote:
>> test_pkg leaked [10, 10, 10] references
>
> This one at least appears to be caused by dummy (deleted) entries in the
> dictionary of interned strings. So it is not really a leak.
On 4/1/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
On 4/1/06, Jim Jewett <
[EMAIL PROTECTED]> wrote:
Nick Coghlan> A simple Boolean attribute (e.g. __finalized__) should be enough. ...> If it's both present and true, the GC can ignore the finaliser on that instanceThat doesn't really take care of
On 4/1/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
Nick Coghlan> A simple Boolean attribute (e.g. __finalized__) should be enough. ...> If it's both present and true, the GC can ignore the finaliser on that instanceThat doesn't really take care of resource release, which needs to be
called, and calle
On 4/1/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
I'm becoming more and more convinced that wedesperately need something better than __del__methods to do finalisation. A garbage collectorthat can't be relied upon to collect garbageis simply not acceptable.
Sure. I don't believe it's too hard, it jus
On 4/1/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
Greg Ewing wrote:> I find it rather worrying that there could be a> few rare cases in which my generators cause> memory leaks, through no fault of my own and> without my being able to do anything about it.
The GC changes PJE is looking at are to ma
On 4/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Terry> For about a week, I have been reading and occasionally posting to
> Terry> the new pydev-3000 mailing list via the gmane mirror
> Terry> gmane.comp.lang.devel.3000. Today, it has disappeared and was
> Terry> still g
27 matches
Mail list logo
