> 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 r
On 1/22/2010 4:38 PM, Tarek Ziadé wrote:
On Sat, Jan 23, 2010 at 1:15 AM, Sridhar Ratnakumar
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 ca
On Sat, Jan 23, 2010 at 1:15 AM, Sridhar Ratnakumar
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 this. (In
> that case
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",
[...]
> 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 2:04 PM, M.-A. Lemburg wrote:
> Karen Tracey wrote:
>> On Fri, Jan 22, 2010 at 7:38 AM, Michael Foord
>> wrote:
>>> 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 = op
On 1/22/2010 2:44 PM, Tarek Ziadé wrote:
On Fri, Jan 22, 2010 at 11:17 PM, Sridhar Ratnakumar
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 s
On Fri, Jan 22, 2010 at 11:17 PM, Sridhar Ratnakumar
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
> http://gist.github.com/279606) in the new, sa
> 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 bac
> 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
On Thu, Jan 21, 2010 at 5:24 PM, Collin Winter wrote:
> On Thu, Jan 21, 2010 at 12:56 PM, Paul Moore 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 strongly *against* this PEP if it w
> 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 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 th
> 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 =
Am 21.01.2010 04:33, schrieb Ben Finney:
> Georg Brandl 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
discuss
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 cProf
On Fri, Jan 22, 2010 at 1:07 PM, Collin Winter wrote:
> Hey Jake,
>
> On Thu, Jan 21, 2010 at 10:48 AM, Jake McGuire wrote:
>> On Thu, Jan 21, 2010 at 10:19 AM, Reid Kleckner wrote:
>>> On Thu, Jan 21, 2010 at 12:27 PM, Jake McGuire wrote:
On Wed, Jan 20, 2010 at 2:27 PM, Collin Winter
>
Hey Jake,
On Thu, Jan 21, 2010 at 10:48 AM, Jake McGuire wrote:
> On Thu, Jan 21, 2010 at 10:19 AM, Reid Kleckner wrote:
>> On Thu, Jan 21, 2010 at 12:27 PM, Jake McGuire wrote:
>>> On Wed, Jan 20, 2010 at 2:27 PM, Collin Winter
>>> wrote:
Profiling
-
Unladen Swall
Karen Tracey wrote:
> On Fri, Jan 22, 2010 at 7:38 AM, Michael Foord
> wrote:
>
>> 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 misunderstan
Hey Tony,
On Fri, Jan 22, 2010 at 10:11 AM, Tony Nelson
wrote:
> On 10-01-22 02:53:21, Collin Winter wrote:
>> On Thu, Jan 21, 2010 at 11:37 PM, Glyph Lefkowitz
>> wrote:
>> >
>> > On Jan 21, 2010, at 6:48 PM, Collin Winter wrote:
> ...
>> > There's been a recent thread on our mailing list abou
On 10-01-22 02:53:21, Collin Winter wrote:
> On Thu, Jan 21, 2010 at 11:37 PM, Glyph Lefkowitz
> 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 of multiproce
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 f
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)
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
Average
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
Pyt
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
http://mail.python
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 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 r
On 22/01/2010 14:33, Antoine Pitrou wrote:
Michael Foord 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
Michael Foord 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 c
On Fri, Jan 22, 2010 at 9:22 AM, Michael Foord wrote:
> 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
> locale.getpreferredencoding() returns".
>
On 22/01/2010 14:18, Karen Tracey wrote:
On Fri, Jan 22, 2010 at 7:38 AM, Michael Foord
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 are
written
On Fri, Jan 22, 2010 at 7:38 AM, Michael Foord wrote:
> 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 e
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 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 Malcolm wrote:
To what extent would it be possible to use (conditionally) use full
ahead-of-time compilation as well as JIT?
It would be
On Wed, Jan 13, 2010 at 1:51 PM, Guido van Rossum 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
> Python-Dev@python.org
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* encod
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 .p
On Jan 21, 2010, at 11:32 PM, Chris Bergstresser wrote:
> On Thu, Jan 21, 2010 at 9:49 PM, Tres Seaver 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 program--is still very
On Jan 21, 2010, at 11:32 PM, Reid Kleckner wrote:
> On Thu, Jan 21, 2010 at 5:07 PM, David Malcolm 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 nearly the same
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
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
42 matches
Mail list logo
