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, raise
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
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
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 sense to you? Does it make
sense
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
the *shortest* possible
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:
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, because
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 zipimporter already
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 long
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,
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.
Regards,
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,
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
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:
DESCRIPTION
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 just had an
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 do with the
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
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 make
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 any
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
IDEs,
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 reloading
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 could do a cache
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:
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
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 part of
[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
26 matches
Mail list logo
