[Herman Geza]
>> Here python reads from an already-freed memory area, right?
[Martin v. Löwis]
> It looks like it, yes. Of course, it could be a flaw in valgrind, too.
> To find out, one would have to understand what the memory block is,
> and what part of PyObject_Free accesses it.
When PyObject
On 11/6/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Herman Geza schrieb:
> > Here python reads from an already-freed memory area, right?
>
> It looks like it, yes. Of course, it could be a flaw in valgrind, too.
> To find out, one would have to understand what the memory block is,
> and what
Herman Geza schrieb:
> Here python reads from an already-freed memory area, right?
It looks like it, yes. Of course, it could be a flaw in valgrind, too.
To find out, one would have to understand what the memory block is,
and what part of PyObject_Free accesses it.
Regards,
Martin
___
Hi!
I've embedded python into my application. Using valgrind I got a lot of
errors. I understand that "Conditional jump or move depends on
uninitialised value(s)" errors are completely ok (from
Misc/README.valgrind). However, I don't understand why "Invalid read"'s
are legal, like this:
==217
"Martin v. Löwis" wrote:
> Greg Ewing schrieb:
>> I think I'd be happy with having to do that explicitly.
>> I expect the vast majority of Python programs don't
>> need to track changes to the set of importable modules
>> during execution. The exceptions would be things like
>> IDEs, and they coul
Greg Ewing schrieb:
> I think I'd be happy with having to do that explicitly.
> I expect the vast majority of Python programs don't
> need to track changes to the set of importable modules
> during execution. The exceptions would be things like
> IDEs, and they could do a cache flush before reloadi
On Tue, 07 Nov 2006 12:20:00 +1300, Greg Ewing <[EMAIL PROTECTED]> wrote:
>
>I think I'd be happy with having to do that explicitly.
>I expect the vast majority of Python programs don't
>need to track changes to the set of importable modules
>during execution. The exceptions would be things like
>I
Martin v. Löwis wrote:
> A stat call will not only look at the directory entry, but also
> look at the inode. This will require another disk access, as the
> inode is at a different location of the disk.
That should be in favour of the directory-reading
approach, since e.g. to find out which if a
tomer filiba wrote:
> cool. first time i build the entire interpreter, 'twas fun :)
> currently i "retained" support for __members__ and __methods__,
> so it doesn't break anything and is compatible with 2.6.
>
> i really hope it will be included in 2.6 as today i'm using ugly hacks
> in RPyC to m
cool. first time i build the entire interpreter, 'twas fun :)
currently i "retained" support for __members__ and __methods__,
so it doesn't break anything and is compatible with 2.6.
i really hope it will be included in 2.6 as today i'm using ugly hacks
in RPyC to make remote objects appear like l
On 11/6/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
Martin v. Löwis wrote:>> Why not only import *.pyc files and no longer use *.pyo files. It is simpler to have one compiled python file extension.>> PYC files can contain optimized python byte code and normal byte
>> code.>> So what would you
Martin v. Löwis wrote:
>> Why not only import *.pyc files and no longer use *.pyo files.
>>
>> It is simpler to have one compiled python file extension.
>> PYC files can contain optimized python byte code and normal byte
>> code.
>
> So what would you do with the -O option of the interpreter?
I j
Fredrik Lundh wrote:
> Andrew Dalke wrote:
>
>
>>>as I said, today's urljoin doesn't guarantee that the output is
>>>the *shortest* possible way to represent the resulting URI.
>>
>>I didn't think anyone was making that claim. The module claims
>>RFC 1808 compliance. From the docstring:
>>
>>
Armin Rigo wrote:
> Typical example: someone in the project removes a .py file, and checks
> in this change; someone else does an 'svn up', which kills the .py in
> his working copy, but not the .pyc. These stale .pyc's cause pain,
> e.g.
> by shadowing the real module (further down sys.path), or
Wolfgang Langner schrieb:
> Why not only import *.pyc files and no longer use *.pyo files.
>
> It is simpler to have one compiled python file extension.
> PYC files can contain optimized python byte code and normal byte code.
So what would you do with the -O option of the interpreter?
Regards,
M
Fredrik Lundh schrieb:
>> urlparse.urljoin("http://blah.com/";, "../")
>>
>> should also give 'http://blah.com/'.
>
> make that: could also give 'http://blah.com/'.
How so? If that would implement RFC 3986, you can
get only a single outcome, if urljoin is meant
to implement section 5 of that RFC.
Armin Rigo schrieb:
> My strong opinion on the matter is that importing a .pyc file if the .py
> file is not present is wrong in the first place.
There is, of course, an important use case (which you are addressing
with a different approach): people want to ship only byte code, not
source code, be
Andrew Dalke schrieb:
> Hence I would say to just grab their library. And perhaps update the
> naming scheme.
Unfortunately, this is not an option. *You* can just grab their library;
the Python distribution can't. Doing so would mean to fork, and history
tells that forks cause problems in the lon
Armin Rigo <[EMAIL PROTECTED]> wrote:
> Hi Martin,
> On Sat, Nov 04, 2006 at 04:47:37PM +0100, "Martin v. L?wis" wrote:
> > Patch #1346572 proposes to also search for .pyc when OptimizeFlag
> > is set, and for .pyo when it is not set. The author argues this is
> > for consistency, as the zipimport
Andrew Dalke wrote:
>> as I said, today's urljoin doesn't guarantee that the output is
>> the *shortest* possible way to represent the resulting URI.
>
> I didn't think anyone was making that claim. The module claims
> RFC 1808 compliance. From the docstring:
>
> DESCRIPTION
> See
Sounds like a good plan, though I'm not sure if it's worth doing in
2.6 -- I'd be happy with doing this just in 3k.
I'm not sure what you mean by "adding a method slot" -- certainly it's
possible to define a method __foo__ and call it directly without
having a special tp_foo in the type object, an
Talin <[EMAIL PROTECTED]> wrote:
>
> Guido van Rossum wrote:
> > I don't know how you define simple. In order to be able to have
> > separate GILs you have to remove *all* sharing of objects between
> > interpreters. And all other data structures, too. It would probably
> > kill performance too,
so, if you remember, i suggested adding __dir__ to objects, so as to make
dir() customizable, remove the deprecated __methods__ and __members__,
and make it symmetrical to other built-in functions.
you can see the original post here:
http://mail.python.org/pipermail/python-dev/2006-July/067095.htm
Andrew:
> >>> urlparse.urljoin("http://blah.com/";, "..")
> 'http://blah.com/'
> >>> urlparse.urljoin("http://blah.com/";, "../")
> 'http://blah.com/../'
> >>> urlparse.urljoin("http://blah.com/";, "../..")
> 'http://blah.com/'
/F:
> as I said, today's urljoin doesn't guarantee that the output is
Martin v. Löwis wrote:
> Andrew Dalke schrieb:
> urlparse.urljoin("http://blah.com/";, "..")
>> 'http://blah.com/'
> urlparse.urljoin("http://blah.com/";, "../")
>> 'http://blah.com/../'
> urlparse.urljoin("http://blah.com/";, "../..")
>> 'http://blah.com/'
>>
>> Does the result make s
Hi Martin,
On Sat, Nov 04, 2006 at 04:47:37PM +0100, "Martin v. L?wis" wrote:
> Patch #1346572 proposes to also search for .pyc when OptimizeFlag
> is set, and for .pyo when it is not set. The author argues this is
> for consistency, as the zipimporter already does that.
My strong opinion on the
Why not only import *.pyc files and no longer use *.pyo files.
It is simpler to have one compiled python file extension.
PYC files can contain optimized python byte code and normal byte code.
--
bye by Wolfgang
___
Python-Dev mailing list
Python-Dev@p
Martin:
> It still should be possible to come up with examples for these as
> well, no? For example, if you pass a relative URI as the base
> URI, what would you like to see happen?
Until two days ago I didn't even realize that was an incorrect
use of urljoin. I can't be the only one. Hence, rai
28 matches
Mail list logo
