valgrind reports a problem when running test_doctest. I haven't
spotted a problem with the code, but the report is consistent (hmm, I
thought there were 3 warnings, but now there's only 1):
==19291== Conditional jump or move depends on uninitialised value(s)
==19291==at 0x49D8B5: maybe_call_l
On 6/16/06, Alexander Belopolsky <[EMAIL PROTECTED]> wrote:
> I would like to share a couple of observations that I made as I
> studied the latest setobject implementation.
...
> 2. Type of several data members in dict-object and dict-entry structs
> were recently changed to Py_ssize_t . Whatever
On 6/18/06, Anthony Baxter <[EMAIL PROTECTED]> wrote:
A question has been asked about branching release25-maint at the timeof beta1. I was actually thinking about doing this for 2.5rc1 - oncewe're in release candidate stage we want to really be careful aboutcheckins. I'm not sure it's worth branchi
"Nick Maclaren" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> experience from times of yore is that emulated floating-point would
> be fast enough that few, if any, Python users would notice.
Perhaps you should enquire on the Python numerical and scientific computing
lists to se
A question has been asked about branching release25-maint at the time
of beta1. I was actually thinking about doing this for 2.5rc1 - once
we're in release candidate stage we want to really be careful about
checkins. I'm not sure it's worth branching at beta1 - it's a bit
more work all round, v
Nick Maclaren wrote:
> 5) I am NOT offering to write a full floating-point emulator, though
> it would be easy enough and could provide repeatable, robust results.
> "Easy" does not mean "quick" :-( Maybe when I retire. Incidentally,
> experience from times of yore is that emulated floating-point
Brett Cannon wrote:
> But it does seem accurate; random checking of some modules that got high
> but not perfect covereage all seem to be instances where dependency
> injection would be required to get the tests to work since they were
> based on platform-specific things.
There's something odd
Guido van Rossum wrote:
>> If it's not the package directory, perhaps it could be a copy of whatever
>> sys.path entry the package was found under - that wouldn't do anything but
>> make "nearby" imports faster.
>
> But it could theoretically affect search order for other modules. I
> still see no
At 06:56 PM 6/18/2006 -0700, Josiah Carlson wrote:
>The non-fast version couldn't actually work if it referenced any names,
>given current Python semantics for arbitrary name binding replacements.
Actually, one could consider "case" expressions to be computed at function
definition time, the way
On 6/12/06, Greg Ward <[EMAIL PROTECTED]> wrote:
> [Guido]
> > While I am an enthusiastic supporter of several of those additions, I
> > am *not* in favor of the special status granted to software
> > contributed by certain developers, since it is a burden for all other
> > developers.
>
> [Martin]
You should be aware of PEP 754 and address it.
http://www.python.org/dev/peps/pep-0754/
Also note that Python conforms to C89, not C99. Any solution should
work on all Python platforms. Some of those platforms are here:
http://www.python.org/dev/buildbot/all/
n
--
On 6/18/06, Brett Cannon <[E
On 6/15/06, Titus Brown <[EMAIL PROTECTED]> wrote:
Folks,I've just run a code coverage report for the python2.4 branch:http://vallista.idyll.org/~t/temp/python2.4-svn/This report uses my figleaf code,
http://darcs.idyll.org/~t/projects/figleaf-latest.tar.gzVery nice, Titus!
I'm int
[skipping answering the numeric-specific questions since I am no math expert =) ]On 6/15/06, Nick Maclaren <[EMAIL PROTECTED]
> wrote:As I have posted to comp.lang.python, I am not happy with Python's
numerical robustness - because it basically propagates the 'features'of IEEE 754 and (worse) C99.
Thomas Lee <[EMAIL PROTECTED]> wrote:
> I see. But restricting the switch to constants in the name of
> performance may not make sense in a language like Python. Maybe this is
> something for the PEP to discuss, but it seems such an implementation
> would be confusing and sometimes it may not be p
On Thu, Jun 15, 2006, dsign wrote:
>
> If not, here's a modified version of the dynload_shlib.c file in:
>
> http://dignor.sign.googlepages.com/dynloadpatchforpython2.4.1
>
> that checks the existence of foo.so.global for module foo.so in the
> same dir and if so, loads it using RTLD_GLOBAL. An u
Talin <[EMAIL PROTECTED]> wrote:
>
> Ok, so in order to clear up the confusion here, I am going to take a
> moment to try and explain Noam's proposal in clearer language.
>
> Now, as to the specifics of Noam's problem: Apparently what he is trying
> to do is what many other people have done, wh
Hi Martin,
The FishEye'd Python Subversion repository is now available here:
http://fisheye3.cenqua.com/browse/python
A big sorry for the delay in actioning this, lost in the email pile :(
Cheers,
Pete.
On 18/04/2006, at 5:16 AM, Martin v. Löwis wrote:
> Peter Moore wrote:
>> I'm responsib
On Thu, Jun 15, 2006 at 10:33:49PM +0200, Alexander Schremmer wrote:
> On Thu, 15 Jun 2006 19:00:09 +0200, Jan Claeys wrote:
>
> > Op di, 13-06-2006 te 10:27 +0200, schreef Alexander Schremmer:
> >> Bazaar-NG seems to reach limits already when working on
> >> it's own code/repository.
> >
> > Ca
As I have posted to comp.lang.python, I am not happy with Python's
numerical robustness - because it basically propagates the 'features'
of IEEE 754 and (worse) C99. Yes, it's better, but I would like to
make it a LOT better. I already have a more robust version of 2.4.2,
but there are some probl
I saw in this list, or some of its relatives, an old discussion between David Abrams, the developer of boost.python, and the devteam of python about loading modules with RTLD_GLOBAL. Many useful comments and a lot of insight, but didn't find a solution to the question posed by David. I don't lik
Folks,
I've just run a code coverage report for the python2.4 branch:
http://vallista.idyll.org/~t/temp/python2.4-svn/
This report uses my figleaf code,
http://darcs.idyll.org/~t/projects/figleaf-latest.tar.gz
I'm interested in feedback on a few things --
* what more would yo
When an extension type Foo defines tp_getattr, but leaves tp_setattr
NULL, an attempt to set an attribute bar results in an AttributeError
with the message "'Foo' object has no attribute 'bar'". This message
is misleading because the object may have the attribute 'bar' as
implemented in tp_getattr
I'm channeling a correspondent, who tells me that Python documentation
(Python 2.5 announcement, and so on) mentions compatibility of sources
with "the MS free compiler"; that's the default toolchain for Windows.
Apparently we're in conflict with Microsoft on that: some hyperlinks
refer to http:/
On Tue, Jun 13, 2006 at 10:27:17AM +0200, Alexander Schremmer wrote:
> Maybe you benchmarked a Tailor deficiency here, but Mercurial scales very
> well. People use it for work on the Linux kernel etc.
> Compared to that, Bazaar-NG seems to reach limits already when working on
> it's own code/reposi
[Guido]
> While I am an enthusiastic supporter of several of those additions, I
> am *not* in favor of the special status granted to software
> contributed by certain developers, since it is a burden for all other
> developers.
[Martin]
> Each maintainer should indicate whether he is happy with a
Hi,
First, sorry for posting this here, I closed my SourceForge account a
few months ago and I can't get it reopened...
I'm using python 2.2.1 but a diff on SVN showed that there was no
change at this level, so the following bug should still be there in
current versions (I'll try with a 2.4 at wo
On 6/11/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
Kevin Jacobs <[EMAIL PROTECTED]> wrote:> Try this at home:> import collections> d=collections.defaultdict(int)> d.iterkeys().next() # Seg fault
> d.iteritems().next() # Seg fault> d.itervalues().next() # Fine and dandyThis all worked fine for me
On Sat, Jun 10, 2006 at 05:53:14PM -0500, [EMAIL PROTECTED] wrote:
>
> Thomas> As the subject of this e-mail says, the attached patch adds a
> Thomas> "switch" statement to the Python language.
>
> Thanks for the contribution. I patched my sandbox and it built just fine.
> I'm going out
On 6/18/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> >You have a point about sys.path[0] being special. It could be the
> >current directory instead of the package directory.
>
> Mightn't that be a security risk, in that it introduces an import hole for
> secure scripts run with -m? Not that I
At 02:03 PM 6/18/2006 -0700, Guido van Rossum wrote:
>On 6/18/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 11:18 AM 6/18/2006 -0700, Guido van Rossum wrote:
> > >On 6/18/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > > > The 'bug fix' solution would be:
> > > >
> > > >1. Change main.c
On 6/18/06, Noam Raphael <[EMAIL PROTECTED]> wrote:
> 2006/6/18, Guido van Rossum <[EMAIL PROTECTED]>:
> > But more to the point, this discussion is pointless, since I won't
> > accept the syntax change.
>
> OK, too bad!
>
> But don't say I haven't warned you, when you will all use my fabulous
> pa
On 6/18/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 11:18 AM 6/18/2006 -0700, Guido van Rossum wrote:
> >On 6/18/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > > The 'bug fix' solution would be:
> > >
> > >1. Change main.c and PySys_SetPath so that '' is NOT prepended to
> > sys.path
>
2006/6/18, Guido van Rossum <[EMAIL PROTECTED]>:
> But more to the point, this discussion is pointless, since I won't
> accept the syntax change.
OK, too bad!
But don't say I haven't warned you, when you will all use my fabulous
package and get tired from typing all those extra parentheses! :)
N
At 11:18 AM 6/18/2006 -0700, Guido van Rossum wrote:
>On 6/18/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > The 'bug fix' solution would be:
> >
> >1. Change main.c and PySys_SetPath so that '' is NOT prepended to
> sys.path
> > when the -m switch is used
> >2. Change runpy.run_module to
At 11:23 AM 6/18/2006 -0700, Guido van Rossum wrote:
>I'm not in favor of abusing this to generate a computed goto, and I
>don't see a need for that -- if we decide to add that (either as
>syntax or as an automatic optimization) I see no problem adding a new
>bytecode.
Me either -- I suggest simpl
On 6/18/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
Georg Brandl wrote:> Georg Brandl wrote:>> In abstract.c, there are many error messages like type_error("object does not support item assignment"); It helps debugging if the object's type was prepended.
>> Should I go through the code and
On 6/18/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:> Ka-Ping Yee wrote:> > Anyway, it looks like someone has added this module to the list of
> > backward-compatible modules in PEP 291. Regarding whether we want> > it to be on that list (i.e. whether or not this backward-compatibility> > shou
Neal Norwitz wrote:
> On 6/18/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>> Anthony Baxter wrote:
>> >> I'd also like to get the new winerror module in before
>> >> beta1 is released - documentation will follow next week:
>> >
>> > Hm. A new python module should be OK - but I was under the impres
On 6/17/06, Armin Rigo <[EMAIL PROTECTED]> wrote:
> The reason is that the details of the stack behavior of END_FINALLY are
> messy in CPython. The finally blocks are the only place where the depth
> of the stack is not known in advance: depending on how the finally block
> is entered, there will
On 6/18/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> The implementations of PEP 328 (explicit relative imports) and PEP 338
> (executing modules as scripts) currently have a fight over the __name__
> attribute of a module.
>
> The -m switch sets __name__ to '__main__', even though it knows the mod
On 6/17/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Talin wrote:
> > The motivation, as I understand it, is one of mathematical consistency.
>
> Noam told me in private email that this is *not* the motivation.
> Instead, he wants mutable values. This, in turn, he wants so he
> can catch modi
2006/6/18, Shane Hathaway <[EMAIL PROTECTED]>:
> Try to think more about how users will use your API. You haven't
> specified where those names (sheet1, income_tax, and profit) are coming
> from. What do you expect users of your library to do to bring those
> names into their namespace?
>
That's
On 6/18/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Anthony Baxter wrote:
> >> I'd also like to get the new winerror module in before
> >> beta1 is released - documentation will follow next week:
> >
> > Hm. A new python module should be OK - but I was under the impression
> > that then large pi
The implementations of PEP 328 (explicit relative imports) and PEP 338
(executing modules as scripts) currently have a fight over the __name__
attribute of a module.
The -m switch sets __name__ to '__main__', even though it knows the module's
real name. This is so that "if __name__ == '__main__
M.-A. Lemburg wrote:
> The winerror module is intended to be able to use symbolic
> names for code using .winerror (much like the errno
> serves this purpose for .errno).
couldn't this be implemented as an extra table in errno instead ?
___
Python-De
Anthony Baxter wrote:
>> I'd also like to get the new winerror module in before
>> beta1 is released - documentation will follow next week:
>
> Hm. A new python module should be OK - but I was under the impression
> that then large piles of the standard library would be updated to use
> this new
Georg Brandl wrote:
> Georg Brandl wrote:
>> In abstract.c, there are many error messages like
>>
>> type_error("object does not support item assignment");
>>
>> It helps debugging if the object's type was prepended.
>> Should I go through the code and try to enhance them
>> where possible?
>
>
Ka-Ping Yee wrote:
> Anyway, it looks like someone has added this module to the list of
> backward-compatible modules in PEP 291. Regarding whether we want
> it to be on that list (i.e. whether or not this backward-compatibility
> should be retained as Python moves forward), i'm happy to have it
>
On Sun, 18 Jun 2006, George Yoshida wrote:
> uuid.py says in its docstring:
> This module works with Python 2.3 or higher.
>
> And my question is:
> Do we plan to make it 2.3 compatible in future releases?
>
> If so, uuid needs to be listed in PEP 291.
> Otherwise, the comment is misleading.
T
Noam Raphael wrote:
> 2006/6/17, "Martin v. Löwis" <[EMAIL PROTECTED]>:
>> Noam Raphael wrote:
>>> I meant the extra code for writing a special class to handle scalars,
>>> if I decide that the "x[()]" syntax is too ugly or too hard to type,
>>> so I write a special class which will allow the synta
50 matches
Mail list logo
