Because the concepts it is based on are no longer used internally -
determining the kind of module is now the province of importlib's finders
and loaders.
--
Sent from my phone, thus the relative brevity :)
On Jul 19, 2012 2:50 AM, "Jim Jewett" wrote:
> Why is inspect.getmoduleinfo() deprecated?
Why is inspect.getmoduleinfo() deprecated? Is it just to remove
circular dependencies?
FWIW, I much prefer an API like:
tell_me_about(object)
to one like:
for test_data in (X, Y, Z):
usable = tester(object, test_data)
if valid(usable):
return possible_result
On 18 Jul, 2012, at 16:59, mar...@v.loewis.de wrote:
>
> Zitat von Ronald Oussoren :
>
>> On 18 Jul, 2012, at 7:53, mar...@v.loewis.de wrote:
>>
What is the status of LLVM nowadays? Is it not a good solution to
write a portable JIT?
>>>
>>> I don't think it is. It is still slow and
Zitat von Ronald Oussoren :
On 18 Jul, 2012, at 7:53, mar...@v.loewis.de wrote:
What is the status of LLVM nowadays? Is it not a good solution to
write a portable JIT?
I don't think it is. It is still slow and memory hungry. The fact that
the version that Apple ships with Xcode still miscom
Hi,
PyUnicode_Join is a public C API function. However, its cousin for the
bytes object is tucked privately in Objects/bytesobject.c as _PyBytes_Join.
Is there any harm in exposing it publicly?
Eli
___
Python-Dev mailing list
Python-Dev@python.org
http:
On Wed, Jul 18, 2012 at 3:35 PM, Eli Bendersky wrote:
> Hi,
>
> PyUnicode_Join is a public C API function. However, its cousin for the
> bytes object is tucked privately in Objects/bytesobject.c as _PyBytes_Join.
> Is there any harm in exposing it publicly?
>
>
A more correctly formulated questio
On 18 Jul, 2012, at 7:53, mar...@v.loewis.de wrote:
>> What is the status of LLVM nowadays? Is it not a good solution to
>> write a portable JIT?
>
> I don't think it is. It is still slow and memory hungry. The fact that
> the version that Apple ships with Xcode still miscompiles Python 3.3
> te
On Wed, Jul 18, 2012 at 7:45 PM, Mark Shannon wrote:
> The practice
>
>
> If you want modest speedup for modest effort, then look at Cesare's WPython.
> Also take a look at Stefan Brunthaler's work on inline caching in an
> interpreter.
>
> If you want a larger speedup then you need t
Some of my (reasonably well informed) opinions on this subject...
The theory
--
Don't think in terms of speeding up your program.
Think in terms of reducing the time spent executing your program.
Performance is improved by removing aspects of the execution overhead.
In a talk I gave at
>
>
> However, it requires that the JIT compiler knows about a lot of
> optimisations. PyPy's JIT is full of those. It's not the fact that it has a
> JIT compiler at all that makes it fast and not the fact that they compile
> Python to machine code, it's the fact that they came up with a huge bunch
On Wed, Jul 18, 2012 at 8:27 AM, Stefan Behnel wrote:
> mar...@v.loewis.de, 18.07.2012 07:53:
> > [Victor Stinner]
> >> I don't want to write my own library to generate machine code.
> >
> > I plan to use nanojit.
>
> As I said, generating machine code is the uninteresting part of it and
> won't
In article
<20120718075314.horde.ty5wc7uwis5qbk9krz1h...@webmail.df.eu>,
mar...@v.loewis.de wrote:
> I don't think it is. It is still slow and memory hungry. The fact that
> the version that Apple ships with Xcode still miscompiles Python 3.3
> tells me that it is still buggy.
Whether LLVM is su
On 18/07/2012 06:55, mar...@v.loewis.de wrote:
Zitat von Mark Lawrence :
On 17/07/2012 23:20, Victor Stinner wrote:
http://psyco.sourceforge.net/ says:
"News, 12 March 2012
Psyco is unmaintained and dead. Please look at PyPy for the
state-of-the-art in JIT compilers for Python."
Victor
13 matches
Mail list logo
