[Python-Dev] str.lstrip bug?
lou xiao writes:
> I find a bug in str.lstrip, when i call str.lstrip, i get this result.
> >>> a.lstrip('device_')
> 'nfo'
> >>>
Try
a.lstrip('_ecived')
You'll see that you get the same result. I suspect that you
misunderstand the meaning of the argument, which is not a sequence of
characters, but a *set* of characters.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.lstrip bug?
On 15-03-10, Facundo Batista wrote:
> On Tue, Mar 10, 2015 at 2:27 PM, lou xiao wrote:
>
> > tiny➜ ~ python
> > Python 2.7.5+ (default, Feb 27 2014, 19:37:08)
> > [GCC 4.8.1] on linux2
> > Type "help", "copyright", "credits" or "license" for more information.
> a='device_info'
> a.lstrip('device')
> > '_info'
> a.lstrip('device_')
> > 'nfo'
>
> On one hand, this is the "development of python itself" list; this
> issue was more aimed to the general python list, of you was sure that
> this is a real bug, to the issue tracker.
>
> On the other hand, this is not a bug! If you pass a parameter to
> lstrip it will (quoted from its help) "remove characters in chars
> instead.", so the moment you pass "device_", it removes all those
> characers from the left... note that the 'i' is removed twice.
That said, I bet this is the most common string-munging operations that *isn't*
available as a single function in the stdlib. I know my bash code is full of
${filename%.suffix} and such, and the fact that in python I have to either
import re or resort to some combination of (starts|ends)with, r?partition,
slicing and an if-clause makes that sort of code much more verbose and harder
to read. Pathlib's Path.with_suffix helps in some but not all of these cases.
Maybe the stdlib should have a simple way to do this? It could even be added as
a kwarg (exact=False) to str.[lr]strip to minimize the effect on the API;
alternatively it could be str.strip(prefix|suffix).
ijs
> Regards,
>
> --
> . Facundo
>
> Blog: http://www.taniquetil.com.ar/plog/
> PyAr: http://www.python.org/ar/
> Twitter: @facundobatista
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/ischwabacher%40wisc.edu
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 488: elimination of PYO files
Hi Brett, On 6 March 2015 at 19:11, Brett Cannon wrote: > I disagree with your premise that .pyo files don't have a noticeable effect > on performance. If you don't use asserts a lot then there is no effect, but > if you use them heavily or have them perform expensive calculations then > there is an impact. Maybe you'd be interested to learn that PyPy (at least the 2.x branch) uses a new bytecode, JUMP_IF_NOT_DEBUG, to conditionally jump over the "assert" line. In "optimized" mode PyPy follows the jumps; in "non-optimized" mode it doesn't. This mode is initialized with the -O flag but can be changed dynamically, as the bytecode is the same. We introduced it as a simple solution to the mess of .pyc versus .pyo. (We didn't consider the case of -OO very closely because PyPy is much bigger than CPython as a binary to start with, so the demand for that is lower.) A bientôt, Armin. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Request for comments: [issue22941] IPv4Interface arithmetic changes subnet mask
Hi,
I'm looking for feedback on issue 22941, "IPv4Interface arithmetic changes
subnet mask".
As stated in the bug, I'd be happy to write a patch, if anyone would comment on
my proposal.
http://bugs.python.org/issue22941
Thank you,
Søren Løvborg
---
Addition and subtraction of integers are documented for ipaddress.IPv4Address
and ipaddress.IPv6Address, but also work for IPv4Interface and IPv6Interface
(though the only documentation of this is a brief mention that the Interface
classes inherit from the respective Address classes). That's good.
The problem is that adding/subtracting an integer to an Interface object
changes the subnet mask (to max_prefixlen), something which is 1) not
documented and 2) not the least surprising result.
>>> import ipaddress
>>> ipaddress.IPv4Interface('10.0.0.1/8') + 1
IPv4Interface('10.0.0.2/32')
>>> ipaddress.IPv6Interface('fd00::1/64') + 1
IPv6Interface('fd00::2/128')
Proposed behavior:
>>> import ipaddress
>>> ipaddress.IPv4Interface('10.0.0.1/8') + 1
IPv4Interface('10.0.0.2/8')
>>> ipaddress.IPv6Interface('fd00::1/64') + 1
IPv6Interface('fd00::2/64')
It all comes down to a judgment call: is this a bug, or expected (but
undocumented) behavior?
In PEP 387 lingo: Is this a "reasonable bug fix"? Or is it a "design mistake",
thus calling for a FutureWarning first, and the actual change later?
>>> ipaddress.IPv4Interface('1.2.3.4/16') + 1
__main__:1: FutureWarning: Arithmetic on IPv4Interface objects will
change in Python 3.6. If you rely on the current behavior, change
'interface + n' to 'IPv4Interface(interface.ip + n, 32)'
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Request for comments: [issue22941] IPv4Interface arithmetic changes subnet mask
On Thu, 12 Mar 2015 12:37:16 +
"Loevborg, Soeren Jakob" wrote:
>
> >>> import ipaddress
> >>> ipaddress.IPv4Interface('10.0.0.1/8') + 1
> IPv4Interface('10.0.0.2/32')
> >>> ipaddress.IPv6Interface('fd00::1/64') + 1
> IPv6Interface('fd00::2/128')
Given that the behaviour is unlikely to match any use case, I'd say
it's a bug.
Related issue:
>>> ipaddress.IPv4Interface('10.0.0.255/8') + 1
IPv4Interface('10.0.1.0/32')
Should the result be IPv4Interface('10.0.0.0/8')
(i.e. wrap around)? Should OverflowError be raised?
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] libffi embedded in CPython
On Wed, Mar 11, 2015 at 8:20 PM Guido van Rossum wrote: > Can we please decouple the ctypes deprecation discussion from efforts to > upgrade cffi? They can coexist just fine, and they don't even really solve > the same problem. > I mostly proposed deprecating ctypes because we were not keeping up with libffi upstream. If we solve the latter I'm not bothered enough to personally pursue the former. -Brett > > On Wed, Mar 11, 2015 at 3:20 PM, Brett Cannon wrote: > >> >> >> On Wed, Mar 11, 2015 at 6:03 PM Paul Moore wrote: >> >>> On 11 March 2015 at 21:45, Maciej Fijalkowski wrote: >>> >> Is it possible to use cffi without a C compiler/headers as easily than >>> >> ctypes? >>> > >>> > yes, it has two modes, one that does that and the other that does >>> > extra safety at the cost of a C compiler >>> >>> So if someone were to propose a practical approach to including cffi >>> into the stdlib, *and* assisting the many Windows projects using >>> ctypes for access to the Windows API [1], then there may be a >>> reasonable argument for deprecating ctypes. But nobody seems to be >>> doing that, rather the suggestion appears to be just to deprecate a >>> widely used part of the stdlib offering no migration path :-( >>> >> >> You're ignoring that it's not maintained, which is the entire reason I >> brought this up. No one seems to want to touch the code. Who knows what >> improvements, bugfixes, etc. exist upstream in libffi that we lack because >> no one wants to go through and figure it out. If someone would come forward >> and help maintain it then I have no issue with it sticking around. >> >> ___ >> Python-Dev mailing list >> [email protected] >> https://mail.python.org/mailman/listinfo/python-dev >> > Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/guido%40python.org >> >> > > > -- > --Guido van Rossum (python.org/~guido) > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] libffi embedded in CPython
On Thu, Mar 12, 2015 at 1:20 AM, Guido van Rossum wrote: > Can we please decouple the ctypes deprecation discussion from efforts to > upgrade cffi? They can coexist just fine, and they don't even really solve > the same problem. > ctypes and cffi do actually solve the same problem, just not in the same way. > > On Wed, Mar 11, 2015 at 3:20 PM, Brett Cannon wrote: > >> >> >> On Wed, Mar 11, 2015 at 6:03 PM Paul Moore wrote: >> >>> On 11 March 2015 at 21:45, Maciej Fijalkowski wrote: >>> >> Is it possible to use cffi without a C compiler/headers as easily than >>> >> ctypes? >>> > >>> > yes, it has two modes, one that does that and the other that does >>> > extra safety at the cost of a C compiler >>> >>> So if someone were to propose a practical approach to including cffi >>> into the stdlib, *and* assisting the many Windows projects using >>> ctypes for access to the Windows API [1], then there may be a >>> reasonable argument for deprecating ctypes. But nobody seems to be >>> doing that, rather the suggestion appears to be just to deprecate a >>> widely used part of the stdlib offering no migration path :-( >>> >> >> You're ignoring that it's not maintained, which is the entire reason I >> brought this up. No one seems to want to touch the code. Who knows what >> improvements, bugfixes, etc. exist upstream in libffi that we lack because >> no one wants to go through and figure it out. If someone would come forward >> and help maintain it then I have no issue with it sticking around. >> >> ___ >> Python-Dev mailing list >> [email protected] >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/guido%40python.org >> >> > > > -- > --Guido van Rossum (python.org/~guido) > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/thomas%40python.org > > -- Thomas Wouters Hi! I'm an email virus! Think twice before sending your email to help me spread! ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] libffi embedded in CPython
I started this message about 3 months ago; at this point I'm just getting it posted so it stops rotting in my Drafts folder. On Mon, Dec 22, 2014 at 3:49 PM, Jim J. Jewett wrote: > On Thu, Dec 18, 2014, at 14:13, Maciej Fijalkowski wrote: >> ... http://bugs.python.org/issue23085 ... >> is there any reason any more for libffi being included in CPython? > > > Paul Moore wrote: >> Probably the easiest way of moving this forward would be for someone >> to identify the CPython-specific patches in the current version ... > > Christian Heimes wrote: >> That's easy. All patches are tracked in the diff file >> https://hg.python.org/cpython/file/3de678cd184d/Modules/_ctypes/libffi.diff > > That (200+ lines) doesn't seem to have all the C changes, such as the > win64 sizeof changes from issue 11835. I took a little bit of time to look at this a while ago. Something that quickly became clear that I'm not sure everybody is on the same page about (I, for one, had no idea previously) is that libffi for Windows and libffi for everything else are entirely separate beasts: the Windows build pulls all of its libffi source from Modules/_ctypes/libffi_msvc and doesn't even touch Modules/_ctypes/libffi (which is libffi for nearly everything else). Most of the files in libffi_msvc haven't been touched in about 4 years, except for a couple fixes by Steve Dower recently. README.ctypes in that folder states that the files were taken from the libffi CVS tree in 2004 and there have been some custom modifications since then, so there is really very little resemblance between libffi_msvc and current libffi. There's also 'libffi_arm_wince' and 'libffi_osx'. I would be fairly amazed if Python itself built on any version of Windows CE; personally I would be for ripping out any supposed support that we have for it (though if somebody is actually using it and it works, it's not hurting anything and should stay). That's a completely different issue, though. I'm all for ditching our 'libffi_msvc' in favor of adding libffi as another 'external' for the Windows build. I have managed to get _ctypes to build on Windows using vanilla libffi sources, prepared using their configure script from within Git Bash and built with our usual Windows build system (properly patched). Unfortunately, making things usable will take some work on ctypes itself, which I'm not qualified to do. I'm happy to pass on my procedure and patches for getting to the point of successful compilation to anyone who feels up to fixing the things that are broken. As for the lightly-patched version of libffi that we keep around for Linux et. al., looking at the diff file I don't see that there's a whole lot of reason to keep it around. -- Zach ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Request for comments: [issue22941] IPv4Interface arithmetic changes subnet mask
On 3/12/2015 10:00 AM, Antoine Pitrou wrote:
> On Thu, 12 Mar 2015 12:37:16 +
> "Loevborg, Soeren Jakob" wrote:
>>
> import ipaddress
> ipaddress.IPv4Interface('10.0.0.1/8') + 1
>> IPv4Interface('10.0.0.2/32')
> ipaddress.IPv6Interface('fd00::1/64') + 1
>> IPv6Interface('fd00::2/128')
>
> Given that the behaviour is unlikely to match any use case, I'd say
> it's a bug.
Agreed.
> Related issue:
>
ipaddress.IPv4Interface('10.0.0.255/8') + 1
> IPv4Interface('10.0.1.0/32')
>
> Should the result be IPv4Interface('10.0.0.0/8')
> (i.e. wrap around)? Should OverflowError be raised?
I think it should be an OverflowError. 10.0.1.0/8 makes no sense, and
10.0.0.0/8 is unlikely to be desirable.
--
Eric.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] libffi embedded in CPython
On Thu, Mar 12, 2015 at 10:39 AM Zachary Ware wrote: > I started this message about 3 months ago; at this point I'm just > getting it posted so it stops rotting in my Drafts folder. > Thanks for looking into this! > > On Mon, Dec 22, 2014 at 3:49 PM, Jim J. Jewett > wrote: > > On Thu, Dec 18, 2014, at 14:13, Maciej Fijalkowski wrote: > >> ... http://bugs.python.org/issue23085 ... > >> is there any reason any more for libffi being included in CPython? > > > > > > Paul Moore wrote: > >> Probably the easiest way of moving this forward would be for someone > >> to identify the CPython-specific patches in the current version ... > > > > Christian Heimes wrote: > >> That's easy. All patches are tracked in the diff file > >> https://hg.python.org/cpython/file/3de678cd184d/Modules/_ > ctypes/libffi.diff > > > > That (200+ lines) doesn't seem to have all the C changes, such as the > > win64 sizeof changes from issue 11835. > > I took a little bit of time to look at this a while ago. Something > that quickly became clear that I'm not sure everybody is on the same > page about (I, for one, had no idea previously) is that libffi for > Windows and libffi for everything else are entirely separate beasts: > the Windows build pulls all of its libffi source from > Modules/_ctypes/libffi_msvc and doesn't even touch > Modules/_ctypes/libffi (which is libffi for nearly everything else). > Most of the files in libffi_msvc haven't been touched in about 4 > years, except for a couple fixes by Steve Dower recently. > README.ctypes in that folder states that the files were taken from the > libffi CVS tree in 2004 and there have been some custom modifications > since then, so there is really very little resemblance between > libffi_msvc and current libffi. > That's what I was afraid of. > > There's also 'libffi_arm_wince' and 'libffi_osx'. I would be fairly > amazed if Python itself built on any version of Windows CE; personally > I would be for ripping out any supposed support that we have for it > (though if somebody is actually using it and it works, it's not > hurting anything and should stay). That's a completely different > issue, though. > > I'm all for ditching our 'libffi_msvc' in favor of adding libffi as > another 'external' for the Windows build. I have managed to get > _ctypes to build on Windows using vanilla libffi sources, prepared > using their configure script from within Git Bash and built with our > usual Windows build system (properly patched). Unfortunately, making > things usable will take some work on ctypes itself, which I'm not > qualified to do. I'm happy to pass on my procedure and patches for > getting to the point of successful compilation to anyone who feels up > to fixing the things that are broken. > So it seems possible to use upstream libffi but will require some work. > > As for the lightly-patched version of libffi that we keep around for > Linux et. al., looking at the diff file I don't see that there's a > whole lot of reason to keep it around. > For UNIX OSs we could probably rely on the system libffi then. What's the situation on OS X? Anyone know if it has libffi, or would be need to be pulled in to be used like on Windows? ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] libffi embedded in CPython
On 12 March 2015 at 17:26, Brett Cannon wrote: >> I'm all for ditching our 'libffi_msvc' in favor of adding libffi as >> another 'external' for the Windows build. I have managed to get >> _ctypes to build on Windows using vanilla libffi sources, prepared >> using their configure script from within Git Bash and built with our >> usual Windows build system (properly patched). Unfortunately, making >> things usable will take some work on ctypes itself, which I'm not >> qualified to do. I'm happy to pass on my procedure and patches for >> getting to the point of successful compilation to anyone who feels up >> to fixing the things that are broken. > > > So it seems possible to use upstream libffi but will require some work. I'd be willing to contemplate helping out on the Windows side of things, if nobody else steps up (with the proviso that I have little free time, and I'm saying this without much idea of what's involved :-)) If Zachary can give a bit more detail on what the work on ctypes is, and/or put what he has somewhere that I could have a look at, that might help. Paul. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Request for comments: [issue22941] IPv4Interface arithmetic changes subnet mask
On 2015-03-12 10:46 AM, Eric V. Smith wrote:
> On 3/12/2015 10:00 AM, Antoine Pitrou wrote:
>> Related issue:
>>
> ipaddress.IPv4Interface('10.0.0.255/8') + 1
>> IPv4Interface('10.0.1.0/32')
>>
>> Should the result be IPv4Interface('10.0.0.0/8')
>> (i.e. wrap around)? Should OverflowError be raised?
>
> I think it should be an OverflowError. 10.0.1.0/8 makes no sense, and
> 10.0.0.0/8 is unlikely to be desirable.
>
No, you are both imbuing meaning to the dot-notation that is not there.
A.B.C.D is just an ugly way to represent a single 32-bit unsigned
integer. The only contentious part would be when your addition would
overlfow the host-portion of the address:
>>> ipaddress.IPv4Interface('10.255.255.255/8') + 1
IPv4Interface('11.0.0.0/8')
However, if you take the perspective that the address is just a 32-bit
unsigned integer, then it makes perfect sense. I would argue it's likely
to be a source of bugs, but I can't say either way because I never
adopted using this library due to issues that are cataloged in the
mailing list archives. (In the end, I wrote my own and have never found
the need to support such operands.)
--
Scott Dial
[email protected]
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Request for comments: [issue22941] IPv4Interface arithmetic changes subnet mask
On Thu, 12 Mar 2015 14:08:01 -0400
Scott Dial wrote:
> On 2015-03-12 10:46 AM, Eric V. Smith wrote:
> > On 3/12/2015 10:00 AM, Antoine Pitrou wrote:
> >> Related issue:
> >>
> > ipaddress.IPv4Interface('10.0.0.255/8') + 1
> >> IPv4Interface('10.0.1.0/32')
> >>
> >> Should the result be IPv4Interface('10.0.0.0/8')
> >> (i.e. wrap around)? Should OverflowError be raised?
> >
> > I think it should be an OverflowError. 10.0.1.0/8 makes no sense, and
> > 10.0.0.0/8 is unlikely to be desirable.
> >
>
> No, you are both imbuing meaning to the dot-notation that is not there.
> A.B.C.D is just an ugly way to represent a single 32-bit unsigned
> integer. The only contentious part would be when your addition would
> overlfow the host-portion of the address:
>
> >>> ipaddress.IPv4Interface('10.255.255.255/8') + 1
> IPv4Interface('11.0.0.0/8')
Oh, well, you're right, I borked my subnet. So, for the record, I meant
"10.0.0.255/24" where the issue actually appears.
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] libffi embedded in CPython
In article , > For UNIX OSs we could probably rely on the system libffi then. What's the > situation on OS X? Anyone know if it has libffi, or would be need to be > pulled in to be used like on Windows? Ronald (in http://bugs.python.org/issue23534): "On OSX the internal copy of libffi that's used is based on the one in PyObjC, which in turn is based on the version of libffi on opensource.apple.com (IIRC with some small patches that fix minor issues found by the PyObjC testsuite)." -- Ned Deily, [email protected] ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] libffi embedded in CPython
On Thu, Mar 12, 2015 at 12:44 PM, Paul Moore wrote: > I'd be willing to contemplate helping out on the Windows side of > things, if nobody else steps up (with the proviso that I have little > free time, and I'm saying this without much idea of what's involved > :-)) If Zachary can give a bit more detail on what the work on ctypes > is, and/or put what he has somewhere that I could have a look at, that > might help. I'll send you everything I've got next chance I have, but I don't know when that will be. -- Zach ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Request for comments: [issue22941] IPv4Interface arithmetic changes subnet mask
On 3/12/2015 2:17 PM, Antoine Pitrou wrote:
> On Thu, 12 Mar 2015 14:08:01 -0400
> Scott Dial wrote:
>
>> On 2015-03-12 10:46 AM, Eric V. Smith wrote:
>>> On 3/12/2015 10:00 AM, Antoine Pitrou wrote:
Related issue:
>>> ipaddress.IPv4Interface('10.0.0.255/8') + 1
IPv4Interface('10.0.1.0/32')
Should the result be IPv4Interface('10.0.0.0/8')
(i.e. wrap around)? Should OverflowError be raised?
>>>
>>> I think it should be an OverflowError. 10.0.1.0/8 makes no sense, and
>>> 10.0.0.0/8 is unlikely to be desirable.
>>>
>>
>> No, you are both imbuing meaning to the dot-notation that is not there.
>> A.B.C.D is just an ugly way to represent a single 32-bit unsigned
>> integer. The only contentious part would be when your addition would
>> overlfow the host-portion of the address:
>>
> ipaddress.IPv4Interface('10.255.255.255/8') + 1
>> IPv4Interface('11.0.0.0/8')
>
> Oh, well, you're right, I borked my subnet. So, for the record, I meant
> "10.0.0.255/24" where the issue actually appears.
I, too, was thinking /24. I think that overflowing the host portion
should raise OverflowError.
--
Eric.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] libffi embedded in CPython
On 12 March 2015 at 18:54, Zachary Ware wrote: > On Thu, Mar 12, 2015 at 12:44 PM, Paul Moore wrote: >> I'd be willing to contemplate helping out on the Windows side of >> things, if nobody else steps up (with the proviso that I have little >> free time, and I'm saying this without much idea of what's involved >> :-)) If Zachary can give a bit more detail on what the work on ctypes >> is, and/or put what he has somewhere that I could have a look at, that >> might help. > > I'll send you everything I've got next chance I have, but I don't know > when that will be. Thanks. No rush :-) Paul ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] libffi embedded in CPython
On Thu, Mar 12, 2015 at 8:35 PM, Ned Deily wrote: > In article > , >> For UNIX OSs we could probably rely on the system libffi then. What's the >> situation on OS X? Anyone know if it has libffi, or would be need to be >> pulled in to be used like on Windows? > > Ronald (in http://bugs.python.org/issue23534): > "On OSX the internal copy of libffi that's used is based on the one in > PyObjC, which in turn is based on the version of libffi on > opensource.apple.com (IIRC with some small patches that fix minor issues > found by the PyObjC testsuite)." > > -- > Ned Deily, > [email protected] >From pypy experience, libffi installed on OS X tends to just work (we never had any issues with those) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] libffi embedded in CPython
On Thu, Mar 12, 2015 at 6:26 PM, Brett Cannon wrote: > > > For UNIX OSs we could probably rely on the system libffi then. > Yes, it's possible to use the system libffi -- that's what most linux distros already do -- but only if you use dynamic linking. If you want to statically link libffi (useful when embedding, making installations that are a little more portable across systems, or when you're a company like Google that wants to statically link all the things) it's a little more confusing. (The reason Brett started this thread is that I mentioned these issues in an internal Google meeting that he happened to be in ;-P) _ctypes currently contains a bunch of duplicate definitions of the ffi_type_* structs (in Modules/_ctypes/cfield.c.) It also contains a separate implementation of ffi_closure_alloc and ffi_closure_free (in Modules/_ctypes/malloc_closure.c) which is only used on OSX. I guess those redefinitions are to cope with (much) older libffis, but that's just a guess. The redefinitions aren't a problem when using dynamic linking, as long as the new definitions aren't incompatible, but if libffi were to change the ABI of the ffi_type structs, yuck. It can be a problem when statically linking, depending on how you link -- and the only reason it works with the bundled libffi is that ctypes *does not build libffi the normal way*. Instead it runs libffi's configure and then selectively builds a few source files from it, using distutils. It would be a really, really good idea to clean up that mess if we're not going to bundle libffi anymore :-P Screaming-and-stabbing-at-setup.py'ly y'rs, -- Thomas Wouters Hi! I'm an email virus! Think twice before sending your email to help me spread! ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
