Thanks Brett and Sridhar for the info. 3to2's version info has been
PEP386-ified, and the latest version can always be found at
http://pypi.python.org/pypi/3to2/ (the previous link will now generate an
error).
--Joe
On Mon, Aug 31, 2009 at 3:25 PM, Brett Cannon wrote:
> On Mon, Aug 31, 2009 at
hi all:
In the svn thunk tree, I find in file Object/funcobject.c, the two
functions: sm_init and cm_init have a little different. the cm_init
function will check the object is really callable, but the sm_init
don't.
the code like this:
if (!PyCallable_Check(callable)) {
PyErr_Format(Py
On Mon, Aug 31, 2009 at 5:01 PM, Greg Ewing wrote:
> Antoine Pitrou wrote:
>
> Did your coworker run any timings instead of basing his assumptions on
>> bytecode
>> size?
>>
>
> In any case, what are you suggesting -- that the last value
> returned by a function call in the body should be the
> d
Antoine Pitrou wrote:
Did your coworker run any timings instead of basing his assumptions on bytecode
size?
In any case, what are you suggesting -- that the last value
returned by a function call in the body should be the
default return value?
I don't think the unpredictability that would int
I was just wondering if a bytecode for a superinstruction of the common
sequence:
6 POP_TOP
7 LOAD_CONST 0 (None)
10 RETURN_VALUE
might be worth it.
[Collin Winter]
I doubt it. You'd save a bit of stack manipulation, but since this
will only appear at the end of a function, I'd be skeptica
Gregory P. Smith krypto.org> writes:
>
> I was just wondering if a bytecode for a superinstruction of the common
sequence:
> 6 POP_TOP
> 7 LOAD_CONST 0 (None)
> 10 RETURN_VALUE
> might be worth it.
I think superinstructions in general would be a good thing to experiment, as
wpytho
2009/8/31 Gregory P. Smith :
> I was just wondering if a bytecode for a superinstruction of the common
> sequence:
>
> 6 POP_TOP
> 7 LOAD_CONST 0 (None)
> 10 RETURN_VALUE
>
> might be worth it.
We could just utilize RETURN_VALUE's op argument.
On Mon, Aug 31, 2009 at 3:07 PM, Gregory P. Smith wrote:
>
>
> On Mon, Aug 31, 2009 at 2:20 PM, Antoine Pitrou wrote:
>>
>> Gregory P. Smith krypto.org> writes:
>> >
>> > food for thought as noticed by a coworker who has been profiling some
>> > hot code
>> to optimize a library...If a function d
On Mon, Aug 31, 2009 at 2:20 PM, Antoine Pitrou wrote:
> Gregory P. Smith krypto.org> writes:
> >
> > food for thought as noticed by a coworker who has been profiling some hot
> code
> to optimize a library...If a function does not have a return statement we
> return
> None. Ironically this mak
On Mon, Aug 31, 2009 at 15:06, P.J. Eby wrote:
> At 02:57 PM 8/31/2009 -0700, Brett Cannon wrote:
>>
>> Ignoring that 'new' is not in Python 3.x (luckily 'types' is), I want
>> a proper solution that doesn't require reconstructing every code
>> object that I happen to import.
>
> Practicality beats
At 02:57 PM 8/31/2009 -0700, Brett Cannon wrote:
Ignoring that 'new' is not in Python 3.x (luckily 'types' is), I want
a proper solution that doesn't require reconstructing every code
object that I happen to import.
Practicality beats purity. ;-) (Especially if it allows importlib
to run on
On Aug 31, 2009, at 4:47 PM, Antoine Pitrou wrote:
I am really not opinionated on this one. I was just pointing out
that choosing a
non-obvious solution generally requires good reasons to do so. The
marshal
format compaction sounds like premature optimization, since nobody
seems to have
for
On Mon, Aug 31, 2009 at 14:52, P.J. Eby wrote:
> At 01:39 PM 8/31/2009 -0700, Brett Cannon wrote:
>>
>> On Mon, Aug 31, 2009 at 12:59, Brett Cannon wrote:
>> > On Mon, Aug 31, 2009 at 12:27, Antoine Pitrou
>> > wrote:
>> >> Brett Cannon python.org> writes:
>> >>>
>> >>> I will plan to take this ap
At 01:39 PM 8/31/2009 -0700, Brett Cannon wrote:
On Mon, Aug 31, 2009 at 12:59, Brett Cannon wrote:
> On Mon, Aug 31, 2009 at 12:27, Antoine Pitrou wrote:
>> Brett Cannon python.org> writes:
>>>
>>> I will plan to take this approach then;
>>> http://bugs.python.org/issue6811 will track all of th
On Fri, Aug 28, 2009 at 2:31 AM, Nick Coghlan wrote:
> Peter Moody wrote:
>> If there are any more suggestions on the PEP or the code, please let me know.
>
> I noticed the new paragraphs on the IPv4 vs IPv6 types not being
> comparable - is there a canonical ordering for mixed address lists
> defi
Gregory P. Smith krypto.org> writes:
>
> food for thought as noticed by a coworker who has been profiling some hot code
to optimize a library...If a function does not have a return statement we return
None. Ironically this makes the foo2 function below faster than the bar2
function at least as m
food for thought as noticed by a coworker who has been profiling some hot
code to optimize a library...
If a function does not have a return statement we return None. Ironically
this makes the foo2 function below faster than the bar2 function at least as
measured using bytecode size:
Python 2.6.
Brett Cannon python.org> writes:
>
> I should also mention that I am +0 on the marshal.load* change. I
> could be convinced to try to pursue a mutable co_filenme direction,
> but considering the BDFL likes the marshal.load* approach and it opens
> up the possibility of compacting the marshal form
On Mon, Aug 31, 2009 at 12:59, Brett Cannon wrote:
> On Mon, Aug 31, 2009 at 12:27, Antoine Pitrou wrote:
>> Brett Cannon python.org> writes:
>>>
>>> I will plan to take this approach then;
>>> http://bugs.python.org/issue6811 will track all of this. Since this is
>>> a 3.2 thing I am not going to
On Mon, Aug 31, 2009 at 12:27, Antoine Pitrou wrote:
> Brett Cannon python.org> writes:
>>
>> I will plan to take this approach then;
>> http://bugs.python.org/issue6811 will track all of this. Since this is
>> a 3.2 thing I am not going to rush to implement this.
>
> I still don't understand what
Brett Cannon python.org> writes:
>
> I will plan to take this approach then;
> http://bugs.python.org/issue6811 will track all of this. Since this is
> a 3.2 thing I am not going to rush to implement this.
I still don't understand what the point is of this complicated approach (adding
an argumen
On Mon, Aug 31, 2009 at 12:18, Sridhar
Ratnakumar wrote:
> On Wed, 26 Aug 2009 15:55:54 -0700, Joe Amenta wrote:
>
>> -- 3to2 is now registered with PyPI. Did I do it right?
>
>> http://pypi.python.org/pypi/3to2/0.1%20alpha%201
>
> Please fix the version number to not contain any whitespace chara
On Mon, Aug 31, 2009 at 06:36, Nick Coghlan wrote:
> Chris Withers wrote:
>> Nick Coghlan wrote:
>>> The PEPs don't go into the process of how we actually hook the command
>>> line up to the runpy module though - that's something you need to dig
>>> into the main.c code to really understand.
>>
>>
On Wed, 26 Aug 2009 15:55:54 -0700, Joe Amenta wrote:
-- 3to2 is now registered with PyPI. Did I do it right?
http://pypi.python.org/pypi/3to2/0.1%20alpha%201
Please fix the version number to not contain any whitespace characters.
Also set the `version` argument in setup(..) in your set
At 09:33 AM 8/31/2009 -0700, Guido van Rossum wrote:
Of course, tracking down all the code objects in the return value of
marshal.load*() might be a bit tricky -- API-wise I still think that
making it an argument to marshal.load*() might be simpler. Also it
would preserve the purity of code objec
On Mon, Aug 31, 2009 at 10:02, Guido van Rossum wrote:
> On Mon, Aug 31, 2009 at 9:57 AM, Brett Cannon wrote:
>> On Mon, Aug 31, 2009 at 09:33, Guido van Rossum wrote:
>>> Hm... I still wonder if there would be bad side effects of making
>>> co_filename writable, but I can't think of any, so maybe
On Mon, Aug 31, 2009 at 9:57 AM, Brett Cannon wrote:
> On Mon, Aug 31, 2009 at 09:33, Guido van Rossum wrote:
>> Hm... I still wonder if there would be bad side effects of making
>> co_filename writable, but I can't think of any, so maybe you can make
>> this work... The next step would be to not w
On Mon, Aug 31, 2009 at 09:33, Guido van Rossum wrote:
> On Mon, Aug 31, 2009 at 9:27 AM, Brett Cannon wrote:
>> On Mon, Aug 31, 2009 at 08:10, Antoine Pitrou wrote:
>>> Benjamin Peterson python.org> writes:
> Why can't we simply make co_filename a writable attribute instead of
>>> inven
On Mon, Aug 31, 2009 at 06:13, Nick Coghlan wrote:
> Brett Cannon wrote:
>>> You can use the C implementation of io, _io, which has a full
>>> buffering implementation. Of course, that also makes it a better
>>> harder for other implementations which may wish to use importlib
>>> because the io lib
On Mon, Aug 31, 2009 at 9:27 AM, Brett Cannon wrote:
> On Mon, Aug 31, 2009 at 08:10, Antoine Pitrou wrote:
>> Benjamin Peterson python.org> writes:
>>>
>>> > Why can't we simply make co_filename a writable attribute instead of
>> inventing
>>> > some complicated API?
>>>
>>> Because code objects
On Mon, Aug 31, 2009 at 08:10, Antoine Pitrou wrote:
> Benjamin Peterson python.org> writes:
>>
>> > Why can't we simply make co_filename a writable attribute instead of
> inventing
>> > some complicated API?
>>
>> Because code objects are supposed to be a immutable hashable object?
>
> Right, but
On Mon, Aug 31, 2009 at 7:49 AM, Robert Brewer wrote:
> CherryPy 3.2 is now in beta, and mod_wsgi is nearly ready as well. Both
> support Python 3. :)
Excellent news! I just saw that PyYAML also suports 3.1. Slowly but
surely, 3.1 is gaining traction...
--
--Guido van Rossum (home page: http://w
Chris Withers wrote:
> Robert Brewer wrote:
you could switch to Python 3.1,
>>> I would love to, once Python 3 has a viable web app story...
>>
>> CherryPy 3.2 is now in beta, and mod_wsgi is nearly ready as well. Both
>> support Python 3. :)
>
> My understanding was that the wsgi spec for Py
Benjamin Peterson python.org> writes:
>
> > Why can't we simply make co_filename a writable attribute instead of
inventing
> > some complicated API?
>
> Because code objects are supposed to be a immutable hashable object?
Right, but co_filename is used neither in tp_hash nor in tp_richcompare.
Robert Brewer wrote:
you could switch to Python 3.1,
I would love to, once Python 3 has a viable web app story...
CherryPy 3.2 is now in beta, and mod_wsgi is nearly ready as well. Both
support Python 3. :)
My understanding was that the wsgi spec for Python 3 wasn't finished...
Chris
--
Si
Chris Withers wrote:
> Guido van Rossum wrote:
> > Being adults about it also means when to give up. Chris, please stop
> > arguing about this.
>
> Sure. Even if people had agreed to this change, it wouldn't end up in
a
> python release I could use for this project.
>
> > There are plenty of tech
2009/8/31 Antoine Pitrou :
> Brett Cannon python.org> writes:
>>
>> Now I can't change
>> co_filename from Python as it's a read-only attribute and thus can't
>> match this functionality in importlib w/o creating some custom code to
>> allow me to specify the co_filename somewhere
>
> Why can't we
Chris Withers wrote:
> Nick Coghlan wrote:
>> The PEPs don't go into the process of how we actually hook the command
>> line up to the runpy module though - that's something you need to dig
>> into the main.c code to really understand.
>
> Yeah, main.c does quite a lot... ;-)
>
> This all spawned
Nick Coghlan gmail.com> writes:
>
> I thought of that question as well, but the later exchange between Guido
> and Brett made me realise that a lot more than the top level module code
> object is affected here - the adjustment also needs to be propagated to
> the code objects created by the modul
Nick Coghlan wrote:
Antoine Pitrou wrote:
Brett Cannon python.org> writes:
Now I can't change
co_filename from Python as it's a read-only attribute and thus can't
match this functionality in importlib w/o creating some custom code to
allow me to specify the co_filename somewhere
Antoine Pitrou wrote:
> Brett Cannon python.org> writes:
>> Now I can't change
>> co_filename from Python as it's a read-only attribute and thus can't
>> match this functionality in importlib w/o creating some custom code to
>> allow me to specify the co_filename somewhere
>
> Why can't we simply
Brett Cannon wrote:
>> You can use the C implementation of io, _io, which has a full
>> buffering implementation. Of course, that also makes it a better
>> harder for other implementations which may wish to use importlib
>> because the io library would have to be completely implemented...
>
> True
Guido van Rossum wrote:
Being adults about it also means when to give up. Chris, please stop
arguing about this.
Sure. Even if people had agreed to this change, it wouldn't end up in a
python release I could use for this project.
There are plenty of techniques you can use to get
what you w
Nick Coghlan wrote:
Ah, OK - I see the problem now. However, I think the current behaviour
is correct, it just needs to be documented better (probably noted in
both the command line doco
Not sure what you mean by this?
regarding sys.path manipulation and in the
doco for site.py).
Agreed :-
Nick Coghlan wrote:
The PEPs don't go into the process of how we actually hook the command
line up to the runpy module though - that's something you need to dig
into the main.c code to really understand.
Yeah, main.c does quite a lot... ;-)
This all spawned from a suggestion by Jim Fulton over
Brett Cannon python.org> writes:
>
> Now I can't change
> co_filename from Python as it's a read-only attribute and thus can't
> match this functionality in importlib w/o creating some custom code to
> allow me to specify the co_filename somewhere
Why can't we simply make co_filename a writable
On Mon, Aug 31, 2009 at 12:08 PM, Gregory P. Smith wrote:
>
>
> On Sun, Aug 30, 2009 at 10:40 PM, Jeroen Ruigrok van der Werven <
> asmo...@in-nomine.org> wrote:
>
>> -On [20090831 06:29], Collin Winter (coll...@gmail.com) wrote:
>> >Are there any application
On Sun, Aug 30, 2009 at 5:24 PM, Guido van Rossum wrote:
> On Sun, Aug 30, 2009 at 4:28 PM, Brett Cannon wrote:
> > I am going through and running the entire test suite using importlib
> > to ferret out incompatibilities. I have found a bunch, although all
> > rather minor (raising a different ex
48 matches
Mail list logo
