On Thu, Jan 21, 2010 at 02:56, Collin Winter wrote:
> Agreed. We are actively working to improve the startup time penalty.
> We're interested in getting guidance from the CPython community as to
> what kind of a startup slow down would be sufficient in exchange for
> greater runtime performance.
+1
My biggest concern is memory usage but it sounds like addressing that is
already in your mind. I don't so much mind an additional up front constant
and per-line-of-code hit for instrumentation but leaks are unacceptable.
Any instrumentation data or jit caches should be managed (and tunable at
> It's true that as Martin said, we can rebase our code to Py3K in a
> branch on python.org any time we like, the question is more "if we do
> the work, will the Python community accept it".
I've stated my personal preference already. Let me add an observation on
top of that: even if the core comm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jack Diederich wrote:
> Does disabling the LLVM change binary compatibility between modules
> targeted at the same version? At tonight's Boston PIG we had some
> binary package maintainers but most people (including myself) only
> cared about source
On Wed, Jan 20, 2010 at 10:13:56PM -0500, Reid Kleckner wrote:
> 2) As a command line option, you can pass -j never. If you have a
> short-lived script, you can just stick this in your #! line and forget
> about it. This has more overhead, since all of the JIT machinery is
> loaded into memory bu
On Wed, Jan 20, 2010 at 19:57, Bill Janssen wrote:
> Reid Kleckner wrote:
>
> > On Wed, Jan 20, 2010 at 8:14 PM, Terry Reedy wrote:
> > > If CPython development moves to distributed hg, the notion of 'blessed'
> > > branches (other than the PSF release branch) will, as I understand it,
> > > be
2010/1/20 Jack Diederich :
> On Wed, Jan 20, 2010 at 5:27 PM, Collin Winter
> wrote:
> [big snip]
>> In order to support hardware and software platforms where LLVM's JIT does not
>> work, Unladen Swallow provides a ``./configure --without-llvm`` option. This
>> flag carves out any part of Unladen
On Wed, Jan 20, 2010 at 5:27 PM, Collin Winter wrote:
[big snip]
> In order to support hardware and software platforms where LLVM's JIT does not
> work, Unladen Swallow provides a ``./configure --without-llvm`` option. This
> flag carves out any part of Unladen Swallow that depends on LLVM, yieldi
Reid Kleckner wrote:
> On Wed, Jan 20, 2010 at 8:14 PM, Terry Reedy wrote:
> > If CPython development moves to distributed hg, the notion of 'blessed'
> > branches (other than the PSF release branch) will, as I understand it,
> > become somewhat obsolete. If you make a branch publicly available,
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.
--
\ “We must respect the other fellow's religion, but only in the |
`\ sense and to the extent that we resp
On Wed, Jan 20, 2010 at 8:14 PM, Terry Reedy wrote:
> If CPython development moves to distributed hg, the notion of 'blessed'
> branches (other than the PSF release branch) will, as I understand it,
> become somewhat obsolete. If you make a branch publicly available, anyone
> can grab it and merge
On Wed, Jan 20, 2010 at 5:56 PM, Collin Winter wrote:
> On Wed, Jan 20, 2010 at 5:14 PM, Terry Reedy wrote:
>> Given the slight benefits compared to the costs, I think this, in its
>> current state, should be optional, such as is psyco.
>>
>> Psyco has a similar time-space tradeoff, except that t
2010/1/20 Ross Cohen :
> Comments? Suggestions? I'm going to continue fixing this up, but was
> wondering if this could possibly make it into python 2.7.
Yes, it could, but please post it to the tracker instead of attaching patches.
--
Regards,
Benjamin
I put together this patch which switches 2.5.4 over to use the newgil.
This was generated by diffing change 76193 (last in the newgil branch)
against change 76189 and applying that on top of the changes listed in
issue 4293 (http://bugs.python.org/issue4293), specifically 68460, 68461
and 68722. Th
Hi Terry,
On Wed, Jan 20, 2010 at 5:14 PM, Terry Reedy wrote:
> Some comments from a non-developer:
>
> The proposal to add this to 3.x seems a bit premature until you have a
> version that runs with 3.x. Not that I expect that to be a problem though.
> If CPython development moves to distributed
Some comments from a non-developer:
The proposal to add this to 3.x seems a bit premature until you have a
version that runs with 3.x. Not that I expect that to be a problem though.
If CPython development moves to distributed hg, the notion of 'blessed'
branches (other than the PSF release br
Martin v. Löwis wrote:
The only supported default encodings in Python are:
Python 2.x: ASCII
Python 3.x: UTF-8
Is this true?
For 3.x: yes. However, the default encoding is much less relevant in
3.x, since Python will never implicitly use the default encoding, except
when some C module
> We're looking forward to discussing this with everyone.
I think the PEP is asking too much (although I can
understand how marketing may have influenced that),
and also asks for permission where none is needed.
It is too broad: it asks (in its title) for the integration of Unladen
Swallow, when
>> The only supported default encodings in Python are:
>>
>> Python 2.x: ASCII
>> Python 3.x: UTF-8
>>
>
> Is this true?
For 3.x: yes. However, the default encoding is much less relevant in
3.x, since Python will never implicitly use the default encoding, except
when some C module asks fo
> Why only set an encoding on these streams when they're directly
> connected to a tty?
If you are sending data to the terminal, you can be fairly certain
that the locale's encoding should be used. It's a convenience feature
for the interactive mode, so that Unicode strings print correctly.
When
On 20/01/2010 21:37, M.-A. Lemburg wrote:
David Malcolm wrote:
I'm thinking of making this downstream change to Fedora's site.py (and
possibly in future RHEL releases) so that the default encoding
automatically picks up the encoding from the locale:
def setencoding():
"""Set the str
Am 20.01.2010 03:43, schrieb David Lyon:
>> Barry was talking about mirrors of the python code. It is true a
>> "package manager" could be developed based on a SCM, however you need
>> to implement this far away from the stdlib and get traction with it
>> within the community long before inclusion
David Malcolm wrote:
> On Wed, 2010-01-20 at 22:37 +0100, M.-A. Lemburg wrote:
> Note that pango isn't even doing the module reload hack; it's written in
> C, and going in directly through the C API:
>PyUnicode_SetDefaultEncoding("utf-8");
>
> I should mention that I've seen at least one C mod
On Wed, 2010-01-20 at 22:37 +0100, M.-A. Lemburg wrote:
> David Malcolm wrote:
> > I'm thinking of making this downstream change to Fedora's site.py (and
> > possibly in future RHEL releases) so that the default encoding
> > automatically picks up the encoding from the locale:
> >
> > def setenco
> Hope this is helpful; can anyone see any potential problems with this
> change?
As Marc-Andre says: such a change is unsupported, and *will* break Python.
It's not true that the only supported encoding in 2.x is 'ascii',
'iso-8859-1' is also supported. 'utf-8' is not, neither is anything
else.
David Malcolm wrote:
> I'm thinking of making this downstream change to Fedora's site.py (and
> possibly in future RHEL releases) so that the default encoding
> automatically picks up the encoding from the locale:
>
> def setencoding():
> """Set the string encoding used by the Unicode implem
David Malcolm wrote:
> I've written up extensive notes on the change and the history of the
> issue here:
> https://fedoraproject.org/wiki/Features/PythonEncodingUsesSystemLocale
>
> Please let me know if there are any errors on that page!
That discussion appears incomplete without any mention of
I'm thinking of making this downstream change to Fedora's site.py (and
possibly in future RHEL releases) so that the default encoding
automatically picks up the encoding from the locale:
def setencoding():
"""Set the string encoding used by the Unicode implementation. The
default is 'a
David Lyon wrote:
> On 2; Who knows what their life cycle is. CVS is pretty much
> dead, and svn looks like it is on the way out.
> I can't think of how anything could be better than
> mercurial or bzr but I know I will be proved wrong.
I believe you misunderstood what Matthieu m
David Lyon pythontest.org> writes:
>
> I think I'll have better chances with PEPs.
>
> Being honest, if wonderful libraries like Sphinx and Mercurial
> and Git and BZR can't make it into the stdlib, then there is
> no hope for even newer code to get in there.
> [snip]
This is python-ideas mater
Barry Warsaw writes:
> (Besides, git in the stdlib doesn't make much sense :).
"Dulwich."
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-d
On Sun, Jan 17, 2010 at 9:42 AM, Dj Gilcrease wrote:
> 2010/1/16 Jack Diederich :
> > Good lord, did this make it past other people's spam filters too? I
> > especially liked the reference to "REGION -2,0 ; Rlyeh". Ph'nglui
> > mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn to you too sir.
>
> Ya ma
> That's only two points. :-)
In French, we say that several starts with 2 ;)
> On 1; If that's true, I won't mention git again.
I tis, you can check on the git repository (it's a mix of C, perl,
shell scripts, Python, ...)
> On 2; Who knows what their life cycle is.
You can check on their web
33 matches
Mail list logo
