On Wed, Mar 27, 2013 at 11:26:51PM -0700, Trent Nelson wrote:
> [ python-dev: I've set up a new list for pyparallel discussions:
> https://lists.snakebite.net/mailman/listinfo/pyparallel. This
> e-mail will be the last I'll send to python-dev@ regarding the
> on-going pyparal
[ python-dev: I've set up a new list for pyparallel discussions:
https://lists.snakebite.net/mailman/listinfo/pyparallel. This
e-mail will be the last I'll send to python-dev@ regarding the
on-going pyparallel work; please drop python-dev@ from the CC
and just send to p
On Tue, Mar 26, 2013 at 11:00 PM, Rocky Bernstein wrote:
> Okay. But is the string is still somewhere in the CPython VM stack? (The
> result of LOAD_CONST 4 above). Is there a way to pick it up from there?
Maybe using C you could peek into the frame's value stack, but that's
not exposed to any Py
On Wed, Mar 27, 2013 at 5:19 PM, Bradley M. Froehle
wrote:
> I implemented just such a path hook zipimporter plus the magic required
> for C extensions --- as a challenge to myself to learn more about the Python
> import mechanisms.
>
> See https://github.com/bfroehle/pydzipimport.
FYI, ther
On 03/26/2013 01:51 PM, Brian Curtin wrote:
Just an FYI that there are under 3 days to apply to Google Summer of
Code for mentoring organizations:
http://www.google-melange.com/gsoc/homepage/google/gsoc2013. The
student application deadline is later on in May.
If you run a project that is intere
On 27 March 2013 21:19, Bradley M. Froehle wrote:
> I implemented just such a path hook zipimporter plus the magic required
> for C extensions --- as a challenge to myself to learn more about the Python
> import mechanisms.
>
> See https://github.com/bfroehle/pydzipimport.
Apologies for hija
On Wed, Mar 27, 2013 at 1:13 PM, Amaury Forgeot d'Arc wrote:
> 2013/3/27 Vinay Sajip
>
>> When you mount a wheel, its absolute path name is added to
>> sys.path, allowing the Python code in it to be imported.
>>
>
> Better: just put the wheel path to sys.path
> sys.path.append('/tmp/simplejso
Daniel Holth gmail.com> writes:
> zipping from ever happening. This is an important reason why wheel is
> billed as an installation format -- fewer users with pitchforks. It's
> very cool that it works though. Debugging is slightly easier than it
> was in the old days because pdb can now read the
Stefan Behnel behnel.de> writes:
> I've always hated this setuptools misfeature of copying C extensions from
> an installed archive into a user directory, one for each user. At least
> during normal installation, they should be properly unpacked into normal
> shared library files in the file sys
Jim Fulton is right that weird failures are a characteristic of zipped
eggs, so one of the #1 requests for setuptools is how to prohibit
zipping from ever happening. This is an important reason why wheel is
billed as an installation format -- fewer users with pitchforks. It's
very cool that it work
Amaury Forgeot d'Arc gmail.com> writes:
> Better: just put the wheel path to sys.path
sys.path.append('/tmp/simplejson-3.1.2-cp27-none-linux_x86_64.whl')
> and let a sys.path_hook entry do the job.
That's what the mount() actually does - adds the wheel to a registry that an
import hook uses.
Vinay Sajip, 27.03.2013 20:38:
> >>> w = Wheel('/tmp/simplejson-3.1.2-cp27-none-linux_x86_64.whl')
> >>> w.mount()
> >>> import simplejson._speedups
> >>> dir(simplejson._speedups)
> ['__doc__', '__file__', '__loader__', '__name__', '__package__',
> 'encode_basestring_ascii', 'make_encoder', 'make
Victor Stinner, 26.03.2013 22:56:
> * what should be the name of "pyc" files?
> * how to handle different configuration of astoptimizer: generate
> different "pyc" files?
You could use (a part of) a crypto hash of the serialised options as part
of the filename. One drawback of a .pyc duplication
2013/3/27 Vinay Sajip
> When you mount a wheel, its absolute path name is added to
> sys.path, allowing the Python code in it to be imported.
>
Better: just put the wheel path to sys.path
sys.path.append('/tmp/simplejson-3.1.2-cp27-none-linux_x86_64.whl')
and let a sys.path_hook entry do the
> This quote is here to stop GMane complaining that I'm top-posting. Ignore.
I've already posted this to distutils-sig, but thought that it might be of
interest to readers here as it relates to importing C extensions ...
zipimport is great, but there can be issues importing software that contains
Andriy Kornatskyy wrote:
> > but you can install this backport from PyPI:
> > https://pypi.python.org/pypi/cdecimal/2.3
>
> This is what I was looking for.
Note that for numerical work _decimal from Python3.3 is vastly faster than
cdecimal. I've added two major speedups (credit for one of them
> No. 2.7 does not accept new features anymore,
It is clear now.
> but you can install this backport from PyPI:
> https://pypi.python.org/pypi/cdecimal/2.3
This is what I was looking for.
Thanks.
Andriy
> Date: Wed, 27 Mar 2013 10:54:37 +0100
> Subject: Re
2013/3/27 Andrew Svetlov
> No. _decimal is new functionality that will never be backported.
>
> On Wed, Mar 27, 2013 at 9:40 AM, Andriy Kornatskyy
> wrote:
> > Any plans backport decimal C implementation from 3.3?
>
No. 2.7 does not accept new features anymore, but you can install
this backport
Andrew,
Thank you for the prompt response back.
> will never be backported.
Who knows?
Is python 3.3 _decimal interface 100% compatible with one pure python
implementation in 2.7?
I suppose code written using decimals in python 2.7 should work in python 3
with no changes, or there should be
No. _decimal is new functionality that will never be backported.
On Wed, Mar 27, 2013 at 9:40 AM, Andriy Kornatskyy
wrote:
> Any plans backport decimal C implementation from 3.3?
>
> Thanks.
>
> Andriy Kornatskyy
>
>
>
>> Date: Tue, 26 Mar 2013 16:18:34 -0
Any plans backport decimal C implementation from 3.3?
Thanks.
Andriy Kornatskyy
> Date: Tue, 26 Mar 2013 16:18:34 -0700
> From: ether@gmail.com
> To: h...@ox.cx
> CC: python-dev@python.org
> Subject: Re: [Python-Dev] [RELEASE] Python 2.7.4 release ca
21 matches
Mail list logo
