Re: [Python-Dev] Request for comments: [issue22941] IPv4Interface arithmetic changes subnet mask
Hi, > I, too, was thinking /24. I think that overflowing the host portion > should raise OverflowError. > Just curiosity, why not a modulo calculation on the subnet instead of raising the error? Thanks in advance! francis ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (ctypes example) libffi embedded in CPython
Hi
>
> It might be a matter of taste, but I don't find declaring C functions
> any more awkward than using strange interface that ctypes comes with.
> the equivalent in cffi would be ffi.cast("double (*)()", x)
- Could you please elaborate on "using strange interface"?
- Is there an easy way to convert the current code using ctypes to
cffi?
Thanks in advance!
francis
___
Python-Dev mailing list
Python-Dev@python.org
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 03/11/2015 06:27 PM, Brett Cannon wrote: > On Mon, Dec 22, 2014 at 4: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. >> >> Besides http://bugs.python.org/issue23085, there is at least >> http://bugs.python.org/issue22733 >> http://bugs.python.org/issue20160 >> http://bugs.python.org/issue11835 >> >> which sort of drives home the point that making sure we have a >> good merge isn't trivial, and this isn't an area where we should >> just assume that tests will catch everything. I don't think it >> is just a quicky waiting on permission. >> >> I've no doubt that upstream libffi is better in many ways, but >> those are ways people have already learned to live with. >> >> That said, I haven't seen any objections in principle, except >> perhaps from Steve Dower in the issues. (I *think* he was >> just saying "not worth the time to me", but it was ambiguous.) >> >> I do believe that Christian or Maciej *could* sort things out well >> enough; I have no insight into whether they have (or someone else >> has) the time to actually do so. >> > > Did anyone ever step forward to do this? I'm a bit worried about the > long-term viability of ctypes if we don't have a maintainer or at least > someone making sure we are staying up-to-date with upstream libffi. my plan was to merge the next libffi release, something along the lines which is released with GCC 5. But this release isn't yet done. ___ Python-Dev mailing list Python-Dev@python.org 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/14/2015 7:04 AM, francis wrote: > Hi, >> I, too, was thinking /24. I think that overflowing the host portion >> should raise OverflowError. >> > Just curiosity, why not a modulo calculation on the subnet instead > of raising the error? Personally, I can't imaging wanting that behavior. I can't say I've ever needed additional at all with an IP address, but if I did, it would only be to stay within the host portion. To wrap around seems odd. If you had a /24 address and added 1000, should that really be the same as adding 232 (= 1000 % 256)? It seems more likely it's an error. I'm +0 on adding addition with an OverflowError for the host portion, and -1 on addition with modulo arithmetic. -- Eric. ___ Python-Dev mailing list Python-Dev@python.org 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/14/2015 4:52 PM, Eric V. Smith wrote: > On 3/14/2015 7:04 AM, francis wrote: >> Hi, >>> I, too, was thinking /24. I think that overflowing the host portion >>> should raise OverflowError. >>> >> Just curiosity, why not a modulo calculation on the subnet instead >> of raising the error? > > Personally, I can't imaging wanting that behavior. I can't say I've ever > needed additional at all with an IP address, but if I did, it would only That should be "I can't say I've ever needed addition at all...". > be to stay within the host portion. To wrap around seems odd. If you had > a /24 address and added 1000, should that really be the same as adding > 232 (= 1000 % 256)? It seems more likely it's an error. > > I'm +0 on adding addition with an OverflowError for the host portion, > and -1 on addition with modulo arithmetic. -- Eric. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Minor update to Python 3.5 release schedule
I always intended all my releases to be on Sundays--that all the release engineering work is done on weekends, which is generally easier for everybody. But I goofed up the 3.5 release schedule and had proposed 3.5.0a3 to be released Saturday March 28th. With the assent of the team I bumped it forward a day to Sunday March 29th. I apologize for my goof. Cheers, //arry/ ___ Python-Dev mailing list Python-Dev@python.org 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
Eric V. Smith writes: > Personally, I can't imaging wanting that behavior. I can't say I've ever > needed additional at all with an IP address, but if I did, it would only > be to stay within the host portion. To wrap around seems odd. It's worse than odd. I've occasionally had use for iterating something like a "ping" over a network, and if I make an off-by-one error "boom" I hit the network address or (probably worse) the broadcast address. The ipaddress module appears to have an __iter__ method on IPv4Network that dtrts. I don't see a real need for an addition operator given that. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] backwards and forwards compatibility, the exact contents of pickle files, and IntEnum
I'm not sure exactly how to phrase this inquiry, so please bear with me. What exactly does backwards compatibility mean as far as pickle goes? We have the various protocols, we have the contents of pickle files created at those protocols, and we have different versions of Python. Should a pickle file created in Python 3.4 with protocol 3 and the contents of socket.AF_INET be unpicklable with a Python 3.3 system? Because currently it cannot be as socket.AF_INET became an IntEnum in 3.4. I'm thinking the answer is yes, it should be. So how do we fix it? There are a couple different options: - modify IntEnum pickle methods to return the name only - modify IntEnum pickle methods to pickle just like the int they represent The first option has the advantage that in 3.4 and above, you'll get back the IntEnum version. The second option has the advantage that the actual pickle contents are the same [1] as in previous versions. So, the final question: Do the contents of a pickle file at a certain protocol have to be the some between versions, or is it enough if unpickling them returns the correct object? -- ~Ethan~ signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] backwards and forwards compatibility, the exact contents of pickle files, and IntEnum
[1] The second option hasn't been coded yet, but the first one has. signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] backwards and forwards compatibility, the exact contents of pickle files, and IntEnum
On 3/14/2015 10:52 PM, Ethan Furman wrote: I'm not sure exactly how to phrase this inquiry, so please bear with me. What exactly does backwards compatibility mean as far as pickle goes? We have the various protocols, we have the contents of pickle files created at those protocols, and we have different versions of Python. Should a pickle file created in Python 3.4 with protocol 3 and the contents of socket.AF_INET be unpicklable with a Python 3.3 system? Because currently it cannot be as socket.AF_INET became an IntEnum in 3.4. I'm thinking the answer is yes, it should be. So how do we fix it? There are a couple different options: - modify IntEnum pickle methods to return the name only - modify IntEnum pickle methods to pickle just like the int they represent The first option has the advantage that in 3.4 and above, you'll get back the IntEnum version. The second option has the advantage that the actual pickle contents are the same [1] as in previous versions. So, the final question: Do the contents of a pickle file at a certain protocol have to be the some between versions, or is it enough if unpickling them returns the correct object? In general, it would seem to me that each version of Python could add object types that are foreign to prior versions, and so as long as version N can unpickle anything produced by versions <=N, all would be well. While I am _not_ an expert in pickle, this would just be my expectation based on years of experience with compatibility issues in non-Python non-pickle systems. Pickle may have stronger compatibility goals than I would expect, and so must you, if you are thinking the answer to the above is "yes, it should be". :) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
