Brett Cannon wrote:
I think the question the PEP is posing is will python-dev accept the
Unladen Swallow work to add an LLVM JIT into the py3k trunk? My
personal answer is yes as it's a nice speed improvement for code that
runs more than once, all while being an optional enhancement for those
Barry Warsaw wrote:
On Jan 21, 2010, at 04:07 PM, Jeffrey Yasskin wrote:
I could imagine a problem if Python+LLVM link in one libstdc++, and an
extension module links in a different one, even if no C++ objects are
passed across the boundary. Does that cause problems in practice? We'd
have
On Jan 21, 2010, at 11:32 PM, Reid Kleckner wrote:
On Thu, Jan 21, 2010 at 5:07 PM, David Malcolm dmalc...@redhat.com wrote:
To what extent would it be possible to use (conditionally) use full
ahead-of-time compilation as well as JIT?
It would be possible to do this, but it doesn't have
On Jan 21, 2010, at 11:32 PM, Chris Bergstresser wrote:
On Thu, Jan 21, 2010 at 9:49 PM, Tres Seaver tsea...@palladion.com wrote:
Generally, that's not going to be the case. But the broader
point--that you've no longer got an especially good idea of what's
taking time to run in your
Reid You could do a static compilation of all code objects in a .pyc to
Reid LLVM IR and compile that to a .so that you load at runtime, but it
Reid just eliminates the interpreter overhead.
OTOH, it would solve the problem some people have distributing their
proprietary apps as .py
On 21/01/2010 21:21, Martin v. Löwis wrote:
Where the default *file system encoding* is used (i.e. text files are
written or read without specifying an encoding)
I think you misunderstand the notion of the *file system encoding*.
It is *not* a file encoding, but the file *system*
On Wed, Jan 13, 2010 at 1:51 PM, Guido van Rossum gu...@python.org wrote:
Please mail me topics you'd like to hear me talk about in my keynote
at PyCon this year.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
On 22/01/2010 11:45, sstein...@gmail.com wrote:
On Jan 21, 2010, at 11:32 PM, Reid Kleckner wrote:
On Thu, Jan 21, 2010 at 5:07 PM, David Malcolmdmalc...@redhat.com wrote:
To what extent would it be possible to use (conditionally) use full
ahead-of-time compilation as well as JIT?
Guido van Rossum wrote:
Please mail me topics you'd like to hear me talk about in my keynote
at PyCon this year.
You might like to comment on the rumored links between the Chinese
Government and the Python Softwamnnn..
On Fri, Jan 22, 2010 at 7:38 AM, Michael Foord fuzzy...@voidspace.org.ukwrote:
On 21/01/2010 21:21, Martin v. Löwis wrote:
Where the default *file system encoding* is used (i.e. text files are
written or read without specifying an encoding)
I think you misunderstand the notion of the *file
On 22/01/2010 14:18, Karen Tracey wrote:
On Fri, Jan 22, 2010 at 7:38 AM, Michael Foord
fuzzy...@voidspace.org.uk mailto:fuzzy...@voidspace.org.uk wrote:
On 21/01/2010 21:21, Martin v. Löwis wrote:
Where the default *file system encoding* is used (i.e.
text files
On Fri, Jan 22, 2010 at 9:22 AM, Michael Foord fuzzy...@voidspace.org.ukwrote:
On 22/01/2010 14:18, Karen Tracey wrote:
The doc here:
http://docs.python.org/3.1/library/functions.html?highlight=open#open just
calls it default encoding and clarifies that is whatever
Michael Foord fuzzyman at voidspace.org.uk writes:
Heh, so we have two different encoding mechanisms both called default
encoding. One is always utf-8 in Python 3 and one is platform
dependent... Great.
The former is merely internal though. Also, if you grep for the s# and s*
argument type
On 22/01/2010 14:33, Antoine Pitrou wrote:
Michael Foordfuzzymanat voidspace.org.uk writes:
Heh, so we have two different encoding mechanisms both called default
encoding. One is always utf-8 in Python 3 and one is platform
dependent... Great.
The former is merely internal though.
sstein...@gmail.com wrote:
On Jan 21, 2010, at 11:32 PM, Chris Bergstresser wrote:
On Thu, Jan 21, 2010 at 9:49 PM, Tres Seaver tsea...@palladion.com wrote:
Generally, that's not going to be the case. But the broader
point--that you've no longer got an especially good idea of what's
Guido van Rossum wrote:
Please mail me topics you'd like to hear me talk about in my keynote
at PyCon this year.
Can you tell us where Uncle Timmy has been and when he'll be back?
___
Python-Dev mailing list
Python-Dev@python.org
On Jan 22, 2010, at 10:06 AM, Chris McDonough wrote:
Can you tell us where Uncle Timmy has been and when he'll be back?
He's given up bags of ham for walls of chocolate.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
ACTIVITY SUMMARY (01/15/10 - 01/22/10)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
2558 open (+37) / 17021 closed (+13) / 19579 total (+50)
Open issues with patches: 1042
John Arbash Meinel, 22.01.2010 15:56:
For example, I've never seen a Pyrex __init__ function show up in
timing, the time spent always gets assigned to the calling function. So
if I want to see it, I set up a 'create_foo(*args, **kwargs)' function
that just does return Foo(*args, **kwargs).
Collin Winter, 21.01.2010 21:14:
Cython is a super-set of Python, and files annotated for maximum
Cython performance are no longer valid Python code, and will not run
on any other Python implementation.
Except when you use plain Python annotations, in which case you get the
speed of Cython for
On 10-01-22 02:53:21, Collin Winter wrote:
On Thu, Jan 21, 2010 at 11:37 PM, Glyph Lefkowitz
gl...@twistedmatrix.com wrote:
On Jan 21, 2010, at 6:48 PM, Collin Winter wrote:
...
There's been a recent thread on our mailing list about a patch that
dramatically reduces the memory footprint
Hey Tony,
On Fri, Jan 22, 2010 at 10:11 AM, Tony Nelson
tonynel...@georgeanelson.com wrote:
On 10-01-22 02:53:21, Collin Winter wrote:
On Thu, Jan 21, 2010 at 11:37 PM, Glyph Lefkowitz
gl...@twistedmatrix.com wrote:
On Jan 21, 2010, at 6:48 PM, Collin Winter wrote:
...
There's been a
Karen Tracey wrote:
On Fri, Jan 22, 2010 at 7:38 AM, Michael Foord
fuzzy...@voidspace.org.ukwrote:
On 21/01/2010 21:21, Martin v. Löwis wrote:
Where the default *file system encoding* is used (i.e. text files are
written or read without specifying an encoding)
I think you misunderstand
Hey Jake,
On Thu, Jan 21, 2010 at 10:48 AM, Jake McGuire mcgu...@google.com wrote:
On Thu, Jan 21, 2010 at 10:19 AM, Reid Kleckner r...@mit.edu wrote:
On Thu, Jan 21, 2010 at 12:27 PM, Jake McGuire mcgu...@google.com wrote:
On Wed, Jan 20, 2010 at 2:27 PM, Collin Winter collinwin...@google.com
On Fri, Jan 22, 2010 at 1:07 PM, Collin Winter collinwin...@google.com wrote:
Hey Jake,
On Thu, Jan 21, 2010 at 10:48 AM, Jake McGuire mcgu...@google.com wrote:
On Thu, Jan 21, 2010 at 10:19 AM, Reid Kleckner r...@mit.edu wrote:
On Thu, Jan 21, 2010 at 12:27 PM, Jake McGuire
Collin Winter wrote:
Hey Jake,
...
Hmm. So cProfile doesn't break, but it causes code to run under a
completely different execution model so the numbers it produces are
not connected to reality?
We've found the call graph and associated execution time information
from cProfile to be
Am 21.01.2010 04:33, schrieb Ben Finney:
Georg Brandl g.bra...@gmx.net writes:
But I've no intention to restrict feature releases to every 18-24
months. What now?
Now we take further discussion to the ‘python-ideas’ forum.
Whoever we is. You can be assured I've not planned any further
Ok, I'm just using the wrong terminology. I'm aware that mbcs is used
for filename encoding on Windows (right?).
Not anymore, no.
The encoding I'm talking
about is the encoding that Python uses to decode a file (or encode a
string) when you do the following in Python 3:
text =
On 1/17/2010 2:09 PM, Tarek Ziadé wrote:
Distribute has
some utility code to handle zip/tar archives. So does PyPM. This is because
the `tarfile` and `zipfile` modules do not just work due to several
issues.
Seehttp://gist.github.com/279606
Take note of the following in the above
I'm not an expert here, but this is why we've tried to avoid exposing
C++ functions into the public API. As long as the public API stays C,
we only require that LLVM and Python are compiled with the same
compiler, right?
Possibly not. You may end up loading two different C++ runtimes into
On Thu, Jan 21, 2010 at 5:24 PM, Collin Winter collinwin...@google.com wrote:
On Thu, Jan 21, 2010 at 12:56 PM, Paul Moore p.f.mo...@gmail.com wrote:
Windows compatibility is a big deal to me. And IMHO, it's a great
strength of Python at the moment that it has solid Windows support. I
would be
But I believe they would be the same set of problems that PEP 384
addresses for cross-version compatibility. Because the linker only sees
the C symbols, it shouldn't be possible for the C++ specific parts of
the runtimes to interfere with each other.
Unfortunately, on systems with a global
It is provided as a separate tool (and often invoked by application
installers) rather than allowing the native code to be distributed
because the results can be system specific.
Actually, they have now changed the implementation: it is now a service
which will do the ngen compilation in
On Fri, Jan 22, 2010 at 11:17 PM, Sridhar Ratnakumar
sridh...@activestate.com wrote:
[..]
3) Patch Lib/tarfile.py to fix issue6196
I am hoping that (1) and (2) will get accepted. But not (3) - in which case,
should this go as a workarond (_ensure_read_write_access in
On 22/01/2010 22:43, Martin v. Löwis wrote:
It is provided as a separate tool (and often invoked by application
installers) rather than allowing the native code to be distributed
because the results can be system specific.
Actually, they have now changed the implementation: it is now a
On 1/22/2010 2:44 PM, Tarek Ziadé wrote:
On Fri, Jan 22, 2010 at 11:17 PM, Sridhar Ratnakumar
sridh...@activestate.com wrote:
[..]
3) Patch Lib/tarfile.py to fix issue6196
I am hoping that (1) and (2) will get accepted. But not (3) - in which case,
should this go as a workarond
On 1/22/2010 2:04 PM, M.-A. Lemburg wrote:
Karen Tracey wrote:
On Fri, Jan 22, 2010 at 7:38 AM, Michael Foord
fuzzy...@voidspace.org.ukwrote:
The encoding I'm talking about is the
encoding that Python uses to decode a file (or encode a string) when you do
the following in Python 3:
[...]
To give an example, what if when Distribute uses `shutil.unpack_archive` to
unpack a sdist from PyPI (the author generated the archive with u-r,u-x set
on files/directoreis -- I've seen this happening before), the subsequent
python setup.py install would fail due to permission issue?
On 1/22/2010 3:19 PM, Tarek Ziadé wrote:
[..]
How about having an extra argument that would fix the permission? (Fixing
the permission is only applicable for tarfile, not zipfile, hence even our
callable will become specific to tarfile).
shutil.unpack_archive(/tmp/foo.tgz, /tmp,
On Sat, Jan 23, 2010 at 1:15 AM, Sridhar Ratnakumar
sridh...@activestate.com wrote:
[..]
Will this callable recieve TarInfo objects if the filetype is tarfile? What
would it receive otherwise? How can `_ensure_read_write_access` be
implemented using this callable? I cannot think of a design for
On 1/22/2010 4:38 PM, Tarek Ziadé wrote:
On Sat, Jan 23, 2010 at 1:15 AM, Sridhar Ratnakumar
sridh...@activestate.com wrote:
[..]
Will this callable recieve TarInfo objects if the filetype is tarfile? What
would it receive otherwise? How can `_ensure_read_write_access` be
implemented
This all begs the question: why is there a default? and why is the
default a guess?
I have to admit that I was completely oblivious to this potential
pitfall, and mostly that's because in the most common case, I am working
with ASCII files.
You answered your own question: it is this reason
42 matches
Mail list logo
