Guido van Rossum writes:
> On Mon, Apr 14, 2014 at 4:02 PM, Donald Stufft wrote:
>> As someone who *has* given back, I can certainly understand why
>> someone would feel that way. It often times *does* feel like
>> CPython doesn’t want contributions.
Sure, but most of the time that feeling
On Mon, Apr 14, 2014 at 10:03 PM, Chris Angelico wrote:
> > How about mirg2**3 (pronounced "migrate") ?
> >
> > ;-)
> >
>
> Just read this, and laughed so loudly and suddenly that my brother's
> cat jumped in fright.
>
> Spelled 2**3 and pronounced 8 makes perfect sense, same as spelling
> "Mercu
On Mon, Apr 14, 2014 at 9:03 PM, Chris Angelico wrote:
> On Tue, Apr 15, 2014 at 7:17 AM, Chris Barker
> wrote:
> > On Mon, Apr 14, 2014 at 1:26 PM, Guido van Rossum
> wrote:
> >
> >>
> >> >> - I'd prefer a name that plays on 2 and 3, not 2 and 8. :-)
> >
> > How about mirg2**3 (pronounced "mig
On Tue, Apr 15, 2014 at 7:17 AM, Chris Barker wrote:
> On Mon, Apr 14, 2014 at 1:26 PM, Guido van Rossum wrote:
>
>>
>> >> - I'd prefer a name that plays on 2 and 3, not 2 and 8. :-)
>
> How about mirg2**3 (pronounced "migrate") ?
>
> ;-)
>
Just read this, and laughed so loudly and suddenly that
On 4/14/2014 5:00 PM, Guido van Rossum wrote:
On Mon, Apr 14, 2014 at 3:53 PM, Terry Reedy mailto:tjre...@udel.edu>> wrote:
If the company is profitable, it could afford
to fund a half- to full-time developer.
By using the vague 'fund' I meant either hire themselves or donate to
PSF
On 4/14/2014 5:16 PM, Donald Stufft wrote:
On Apr 14, 2014, at 4:39 PM, Guido van Rossum mailto:gu...@python.org>> wrote:
On Mon, Apr 14, 2014 at 4:02 PM, Donald Stufft mailto:don...@stufft.io>> wrote:
On Apr 14, 2014, at 3:53 PM, Terry Reedy mailto:tjre...@udel.edu>> wrote:
> O
Guido van Rossum wrote:
Some quick thoughts:
- I'd prefer a name that plays on 2 and 3, not 2 and 8. :-)
Python Twee?
Or maybe Python Tween, as in "between 2 and 3".
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/
On 4/14/2014 2:51 PM, Brett Cannon wrote:
Freezing everything except encodings.__init__, os, and _sysconfigdata,
I suppose these are omitted because they can vary in different environments?
But isn't Python built for a particular environment... seems like os
could be included?
Seems like it
On Mon, Apr 14, 2014 at 6:07 PM, Glenn Linderman wrote:
> On 4/14/2014 2:51 PM, Brett Cannon wrote:
>
> consider freezing all the modules
>
> ...
>
> Now the question is whether the maintenance cost of having to rebuild
> Python for a select number of stdlib modules
>
>
> "all" versus "select n
On Mon, Apr 14, 2014 at 9:32 AM, Steve Dower wrote:
[snip]
> The two important components of Python 2migr8 would be the ability to disable
> 2.7-only features, and to do so on a module-by-module basis.
This should be doable with an import hook. For that matter it would
be pretty straight-forwar
On Mon, Apr 14, 2014 at 6:15 PM, Skip Montanaro wrote:
> On Mon, Apr 14, 2014 at 4:51 PM, Brett Cannon wrote:
> > Thoughts?
>
> Interesting idea, but YAGNI?
>
Not at all. Think of every script you execute that's written in Python. One
of the things the Mercurial folks say is hindering any motiv
On Mon, Apr 14, 2014 at 4:51 PM, Brett Cannon wrote:
> Thoughts?
Interesting idea, but YAGNI?
In my work environment (Python 2.7.2, all the heavy lifting done in
C++), startup costs are dominated by dynamic linking of all our C++
libraries and their Boost wrappers:
% time python -c 'import trad
On 4/14/2014 2:51 PM, Brett Cannon wrote:
consider freezing all the modules
...
Now the question is whether the maintenance cost of having to rebuild
Python for a select number of stdlib modules
"all" versus "select number".
So I'm guessing the proposal is to freeze all the modules that Pyth
It was realized during PyCon that since we are freezing importlib we could
now consider freezing all the modules to cut out having to stat or read
them from disk. So for day 1 of the sprints I I decided to hack up a
proof-of-concept to see what kind of performance gain it would get.
Freezing every
On 14/04/2014 22:17, Chris Barker wrote:
On Mon, Apr 14, 2014 at 1:26 PM, Guido van Rossum mailto:gu...@python.org>> wrote:
>> - I'd prefer a name that plays on 2 and 3, not 2 and 8. :-)
How about mirg2**3 (pronounced "migrate") ?
;-)
-Chris
I agree with the grate part. Failing that
On Mon, Apr 14, 2014 at 1:26 PM, Guido van Rossum wrote:
> >> - I'd prefer a name that plays on 2 and 3, not 2 and 8. :-)
>
How about mirg2**3 (pronounced "migrate") ?
;-)
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R(206) 526-695
On Apr 14, 2014, at 4:39 PM, Guido van Rossum wrote:
> On Mon, Apr 14, 2014 at 4:02 PM, Donald Stufft wrote:
>
> On Apr 14, 2014, at 3:53 PM, Terry Reedy wrote:
>
> > On 4/14/2014 11:32 AM, Steve Dower wrote:
> [...]
> >> However unfair
> >> and incorrect it may be, there is a perception in
On Mon, Apr 14, 2014 at 3:53 PM, Terry Reedy wrote:
> On 4/14/2014 11:32 AM, Steve Dower wrote:
>
[...]
>
The main trigger was a conversation I had with two employees of a
>> very large bank that has about 3000 Python users (not developers -
>> mostly financial analysts) and 16 million lines of
On Mon, Apr 14, 2014 at 4:02 PM, Donald Stufft wrote:
>
> On Apr 14, 2014, at 3:53 PM, Terry Reedy wrote:
>
> > On 4/14/2014 11:32 AM, Steve Dower wrote:
> [...]
> >> However unfair
> >> and incorrect it may be, there is a perception in some businesses
> >> that open-source projects do not want
On 04/14/2014 08:36 AM, Benjamin Peterson wrote:
On Sun, Apr 13, 2014, at 22:39, Nathaniel Smith wrote:
SO, we'd like to route our allocations through PyMem_* in order to let
tracemalloc "see" them, but because there is no PyMem_*Calloc, doing
this would force us to give up on the calloc() opti
On Apr 14, 2014 2:42 PM, "Terry Reedy" wrote:
>
> On 4/14/2014 1:19 PM, Guido van Rossum wrote:
>>
>> Some quick thoughts:
>>
>> - I'd prefer a name that plays on 2 and 3, not 2 and 8. :-)
>>
>> - Are you sure this isn't better directed to python-ideas first? Most
>> ideas have to prove their wort
On Apr 14, 2014, at 3:53 PM, Terry Reedy wrote:
> On 4/14/2014 11:32 AM, Steve Dower wrote:
>
>> To put it up front, I'm totally against "CPython 2.8" ever becoming a
>> real thing. Anything that comes out should be seen as a migration
>> path, not an upgrade path. I'll also admit I'm not heavi
On 4/14/2014 11:32 AM, Steve Dower wrote:
To put it up front, I'm totally against "CPython 2.8" ever becoming a
real thing. Anything that comes out should be seen as a migration
path, not an upgrade path. I'll also admit I'm not heavily invested
in working on it myself, but I had a number of con
On 4/14/2014 1:19 PM, Guido van Rossum wrote:
Some quick thoughts:
- I'd prefer a name that plays on 2 and 3, not 2 and 8. :-)
- Are you sure this isn't better directed to python-ideas first? Most
ideas have to prove their worth in that list before python-dev will give
them the light of day.
-
Some quick thoughts:
- I'd prefer a name that plays on 2 and 3, not 2 and 8. :-)
- Are you sure this isn't better directed to python-ideas first? Most ideas
have to prove their worth in that list before python-dev will give them the
light of day.
- When it comes to purely syntactic issues (e.g.
On Mon, Apr 14, 2014, at 9:14, Zachary Ware wrote:
> On Mon, Apr 14, 2014 at 10:52 AM, benjamin.peterson
> wrote:
> > http://hg.python.org/cpython/rev/4bd1fb0f4f44
> > changeset: 90256:4bd1fb0f4f44
> > branch: 3.1
> > parent: 90235:a8facac493ef
> > user:Benjamin Peterson
> >
On Mon, Apr 14, 2014 at 10:52 AM, benjamin.peterson
wrote:
> http://hg.python.org/cpython/rev/4bd1fb0f4f44
> changeset: 90256:4bd1fb0f4f44
> branch: 3.1
> parent: 90235:a8facac493ef
> user:Benjamin Peterson
> date:Mon Apr 14 11:45:21 2014 -0400
> summary:
> disallow
On Tue, Apr 15, 2014 at 1:32 AM, Steve Dower wrote:
> My best idea so far would be to have a magic comment (to ensure 2.7
> compatibility better than a "from __future__ ...") near the top of the file
> that marks that file as "must straddle 2.7 and 3.3". Adding this comment
> causes (for exampl
On Sun, Apr 13, 2014, at 22:39, Nathaniel Smith wrote:
> Hi all,
>
> The new tracemalloc infrastructure in python 3.4 is super-interesting
> to numerical folks, because we really like memory profiling. Numerical
> programs allocate a lot of memory, and sometimes it's not clear which
> operations a
Just in case there's anyone out there who isn't yet sick of discussing how to
proceed with Python 2.7, I have some more inputs to contribute.
To put it up front, I'm totally against "CPython 2.8" ever becoming a real
thing. Anything that comes out should be seen as a migration path, not an
upg
Hi all,
The new tracemalloc infrastructure in python 3.4 is super-interesting
to numerical folks, because we really like memory profiling. Numerical
programs allocate a lot of memory, and sometimes it's not clear which
operations allocate memory (some numpy operations return views of the
original
On Mon, 14 Apr 2014 08:18:13 -0400, Nick Coghlan wrote:
> On 14 Apr 2014 01:56, "Stephen J. Turnbull" wrote:
> >
> > mar...@v.loewis.de writes:
> >
> > > For gaining commit access, it's really more important that the patch
> > > is factually finished, than that it's author believes it to. If pe
On 14 Apr 2014 01:56, "Stephen J. Turnbull" wrote:
>
> mar...@v.loewis.de writes:
>
> > For gaining commit access, it's really more important that the patch
> > is factually finished, than that it's author believes it to. If people
> > get it right the first time often enough, they get commit a
On Sun, Apr 13, 2014 at 9:51 PM, "Martin v. Löwis" wrote:
> As I just said: to get started, run the current build process. Without
> knowing WiX in detail, I'd still claim that msi.py is superiour in
> terms of expressiveness (i.e. it can better compute what files go into
> the MSI). I'm almost ce
34 matches
Mail list logo
