Re: [Python-Dev] stat module in C -- what to do with stat.py?
On Fri, Jun 21, 2013 at 11:06 AM, Nick Coghlan ncogh...@gmail.com wrote: On 21 June 2013 01:04, Thomas Wouters tho...@python.org wrote: If the .py file is going to be wrong or incomplete, why would we want to keep it -- or use it as fallback -- at all? If we're dead set on having a .py file instead of requiring it to be part of the interpreter (whichever that is, however it was built), it should be generated as part of the build process. Personally, I don't see the value in it; other implementations will need to do *something* special to use it anyway. Because practicality beats purity. This wrong Python code has been good enough for all Python version up until 3.4, it makes sense to keep it as a fallback instead of throwing it away. How would you know if the Python you're running on has an incorrect bitflag? If the wrong code is simply incomplete (it has the standard flags but none of the contended ones), that would at least be safe - you'll never get a false flag, but you might be unable to recognize the platform-specific ones. And then the platform-specific modules would always be adding, never overwriting, bitflags. ChrisA ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] stat module in C -- what to do with stat.py?
2013/6/21 Nick Coghlan ncogh...@gmail.com: Because practicality beats purity. This wrong Python code has been good enough for all Python version up until 3.4, it makes sense to keep it as a fallback instead of throwing it away. How do you plan to handle the following case in Python? Looking in more detail: for the S_IFMT flags, OSX/Darwin/FreeBSD defines 0xe000 as S_IFWHT (whiteout), but Solaris defines it as S_IFPORT (event port). We may keep the Python module if it is kept unchanged, but the Python and C modules should have the same public API (the C module should not have more features). Or should play with if sys.platform == ...? Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 409 and the stdlib
On 05/21/2013 10:36 AM, Serhiy Storchaka wrote: 21.05.13 10:17, Hrvoje Niksic написав(ла): On 05/20/2013 05:15 PM, Ethan Furman wrote: 1) Do nothing and be happy I use 'raise ... from None' in my own libraries 2) Change the wording of 'During handling of the above exception, another exception occurred' (no ideas as to what at the moment) The word occurred misleads one to think that, during handling of the real exception, an unrelated and unintended exception occurred. This is not the case when the raise keyword is used. In that case, the exception was intentionally *converted* from one type to another. For the raise case a wording like the following might work better: The above exception was converted to the following exception: ... That makes it clear that the conversion was explicit and (hopefully) intentional, and that the latter exception supersedes the former. How do you distinguish intentional and unintentional exceptions? By the use of the raise keyword. Given the code: try: x = bla['foo'] except KeyError: raise BusinessError(...) ...explicit raise is a giveaway that the exception replacement was quite intentional. Hrvoje ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] stat module in C -- what to do with stat.py?
On 21 June 2013 17:25, Victor Stinner victor.stin...@gmail.com wrote: 2013/6/21 Nick Coghlan ncogh...@gmail.com: Because practicality beats purity. This wrong Python code has been good enough for all Python version up until 3.4, it makes sense to keep it as a fallback instead of throwing it away. How do you plan to handle the following case in Python? Looking in more detail: for the S_IFMT flags, OSX/Darwin/FreeBSD defines 0xe000 as S_IFWHT (whiteout), but Solaris defines it as S_IFPORT (event port). We may keep the Python module if it is kept unchanged, but the Python and C modules should have the same public API (the C module should not have more features). I think it's OK to expose additional platform specific features in the C version, and have them fail cleanly with the pure Python version (rather than silently giving the wrong answer). What's not OK is for the standard library to regress for other implementations just because we added a C implementation for the benefit of CPython. That's exactly the kind of thing PEP 399 says we *won't* do. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] stat module in C -- what to do with stat.py?
Le Fri, 21 Jun 2013 21:39:10 +1000, Nick Coghlan ncogh...@gmail.com a écrit : On 21 June 2013 17:25, Victor Stinner victor.stin...@gmail.com wrote: 2013/6/21 Nick Coghlan ncogh...@gmail.com: Because practicality beats purity. This wrong Python code has been good enough for all Python version up until 3.4, it makes sense to keep it as a fallback instead of throwing it away. How do you plan to handle the following case in Python? Looking in more detail: for the S_IFMT flags, OSX/Darwin/FreeBSD defines 0xe000 as S_IFWHT (whiteout), but Solaris defines it as S_IFPORT (event port). We may keep the Python module if it is kept unchanged, but the Python and C modules should have the same public API (the C module should not have more features). I think it's OK to expose additional platform specific features in the C version, and have them fail cleanly with the pure Python version (rather than silently giving the wrong answer). PEP 399 says we don't do it: Acting as a drop-in replacement also dictates that no public API be provided in accelerated code that does not exist in the pure Python code. Without this requirement people could accidentally come to rely on a detail in the accelerated code which is not made available to other VMs that use the pure Python implementation. What's not OK is for the standard library to regress for other implementations just because we added a C implementation for the benefit of CPython. That's exactly the kind of thing PEP 399 says we *won't* do. For me, PEP 399 should not be considered a requirement but a guideline. stat.py is algorithmically trivial and I don't think it saves much work for authors of third-party Python implementations. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] stat module in C -- what to do with stat.py?
Am 21.06.2013 13:45, schrieb Antoine Pitrou: For me, PEP 399 should not be considered a requirement but a guideline. stat.py is algorithmically trivial and I don't think it saves much work for authors of third-party Python implementations. The module's content is rather boring. It's just a bunch of constants, some wrapper functions for macros and one trivial function that turns st_mode into -rwxr-xr-x string. In my opinion stat module falls into the same line as the errno module. The latter is also implemented in C in order to pull a bunch of constants from header files. I have yet another argument in favor of a C implementation. POSIX standards won't gain any new S_IF* numeric constants for new files types. Some file types such as mq, semaphore, shmem and typed memory from POSIX real time extensions aren't testable with S_IF*, too. (But I don't know any platform that implements them as files, though). http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_stat.h.html#tag_13_61_06 Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] stat module in C -- what to do with stat.py?
On 6/21/2013 7:39 AM, Nick Coghlan wrote: On 21 June 2013 17:25, Victor Stinner victor.stin...@gmail.com wrote: 2013/6/21 Nick Coghlan ncogh...@gmail.com: Because practicality beats purity. This wrong Python code has been good enough for all Python version up until 3.4, it makes sense to keep it as a fallback instead of throwing it away. How do you plan to handle the following case in Python? Looking in more detail: for the S_IFMT flags, OSX/Darwin/FreeBSD defines 0xe000 as S_IFWHT (whiteout), but Solaris defines it as S_IFPORT (event port). We may keep the Python module if it is kept unchanged, but the Python and C modules should have the same public API (the C module should not have more features). I think it's OK to expose additional platform specific features in the C version, and have them fail cleanly with the pure Python version (rather than silently giving the wrong answer). What's not OK is for the standard library to regress for other implementations just because we added a C implementation for the benefit of CPython. That's exactly the kind of thing PEP 399 says we *won't* do. I was just writing up something similar. But as always, Nick said it better than me. -- Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [python 2.7] a question about exporting a new method to socket object
Hi python devs :
As a part of exploring an idea, I am trying to add a new method to the
python socket object. Here's what I have been trying to do (the patch may
be whitespace damaged so please bear with me) :
Index: Python-2.7/Modules/socketmodule.c
===
--- Python-2.7.orig/Modules/socketmodule.c
+++ Python-2.7/Modules/socketmodule.c
@@ -126,6 +126,7 @@ makefile([mode, [bufsize]]) -- return a
recv(buflen[, flags]) -- receive data\n\
recv_into(buffer[, nbytes[, flags]]) -- receive data (into a buffer)\n\
recvfrom(buflen[, flags]) -- receive data and sender\'s address\n\
+arecvfrom(buflen[, flags]) -- same as recvfrom \n\
recvfrom_into(buffer[, nbytes, [, flags])\n\
-- receive data and sender\'s address (into a buffer)\n\
sendall(data[, flags]) -- send all data\n\
@@ -468,6 +469,13 @@ static PyTypeObject sock_type;
#define IS_SELECTABLE(s) ((s)-sock_fd FD_SETSIZE || s-sock_timeout =
0.0)
#endif
@@ -2620,6 +2802,58 @@ PyDoc_STRVAR(recvfrom_doc,
\n\
Like recv(buffersize, flags) but also return the sender's address info.);
+static PyObject *
+sock_arecvfrom(PySocketSockObject *s, PyObject *args)
+{
+return sock_recvfrom(s,args);
+}
+
+PyDoc_STRVAR(arecvfrom_doc,
+arecvfrom(buffersize[, flags]) - (data, address info)\n\
+\n\
+ experimental stuff);
/* s.recvfrom_into(buffer[, nbytes [,flags]]) method */
@@ -2963,6 +3197,8 @@ static PyMethodDef sock_methods[] = {
recv_into_doc},
{recvfrom, (PyCFunction)sock_recvfrom, METH_VARARGS,
recvfrom_doc},
+{arecvfrom, (PyCFunction)sock_arecvfrom, METH_VARARGS,
+ arecvfrom_doc},
{recvfrom_into, (PyCFunction)sock_recvfrom_into, METH_VARARGS |
METH_KEYWORDS,
recvfrom_into_doc},
{send, (PyCFunction)sock_send, METH_VARARGS,
When I compile this and run a simple script like the following that uses
arecvfrom() :
sock = socket.socket( socket.PF_PACKET, socket.SOCK_RAW )
sock.bind( ( intf, ETH_P_ALL ) )
(pkt,dontcare) = dst.arecvfrom( 500, socket.MSG_DONTWAIT )
I get this exception :
AttributeError: '_socketobject' object has no attribute 'arecvfrom'
So what am I doing wrong? How do I export this new socket method?
any help/pointer will be greatly appreciated.
cheers,
ani
--
Ani
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [python 2.7] a question about exporting a new method to socket object
Technically this list isn't the right place, but you probably are
bitten by the duplication of functionality in Lib/socket.py. There's a
list of methods at the top of that file, _socketmethods.
But you really shouldn't be asking here -- this list is for changes to
Python, not using or hacking it. (Try StackOverflow for that.)
--Guido
On Thu, Jun 20, 2013 at 10:18 PM, Ani Sinha a...@aristanetworks.com wrote:
Hi python devs :
As a part of exploring an idea, I am trying to add a new method to the
python socket object. Here's what I have been trying to do (the patch may be
whitespace damaged so please bear with me) :
Index: Python-2.7/Modules/socketmodule.c
===
--- Python-2.7.orig/Modules/socketmodule.c
+++ Python-2.7/Modules/socketmodule.c
@@ -126,6 +126,7 @@ makefile([mode, [bufsize]]) -- return a
recv(buflen[, flags]) -- receive data\n\
recv_into(buffer[, nbytes[, flags]]) -- receive data (into a buffer)\n\
recvfrom(buflen[, flags]) -- receive data and sender\'s address\n\
+arecvfrom(buflen[, flags]) -- same as recvfrom \n\
recvfrom_into(buffer[, nbytes, [, flags])\n\
-- receive data and sender\'s address (into a buffer)\n\
sendall(data[, flags]) -- send all data\n\
@@ -468,6 +469,13 @@ static PyTypeObject sock_type;
#define IS_SELECTABLE(s) ((s)-sock_fd FD_SETSIZE || s-sock_timeout =
0.0)
#endif
@@ -2620,6 +2802,58 @@ PyDoc_STRVAR(recvfrom_doc,
\n\
Like recv(buffersize, flags) but also return the sender's address info.);
+static PyObject *
+sock_arecvfrom(PySocketSockObject *s, PyObject *args)
+{
+return sock_recvfrom(s,args);
+}
+
+PyDoc_STRVAR(arecvfrom_doc,
+arecvfrom(buffersize[, flags]) - (data, address info)\n\
+\n\
+ experimental stuff);
/* s.recvfrom_into(buffer[, nbytes [,flags]]) method */
@@ -2963,6 +3197,8 @@ static PyMethodDef sock_methods[] = {
recv_into_doc},
{recvfrom, (PyCFunction)sock_recvfrom, METH_VARARGS,
recvfrom_doc},
+{arecvfrom, (PyCFunction)sock_arecvfrom, METH_VARARGS,
+ arecvfrom_doc},
{recvfrom_into, (PyCFunction)sock_recvfrom_into, METH_VARARGS |
METH_KEYWORDS,
recvfrom_into_doc},
{send, (PyCFunction)sock_send, METH_VARARGS,
When I compile this and run a simple script like the following that uses
arecvfrom() :
sock = socket.socket( socket.PF_PACKET, socket.SOCK_RAW )
sock.bind( ( intf, ETH_P_ALL ) )
(pkt,dontcare) = dst.arecvfrom( 500, socket.MSG_DONTWAIT )
I get this exception :
AttributeError: '_socketobject' object has no attribute 'arecvfrom'
So what am I doing wrong? How do I export this new socket method?
any help/pointer will be greatly appreciated.
cheers,
ani
--
Ani
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [python 2.7] a question about exporting a new method to socket object
Hi Ani,
just a simple question:
Are you sure, that you imported the modified socket module and not the original
module from the distribution?
HTH,
Gerald
Am 21.06.2013 um 07:18 schrieb Ani Sinha a...@aristanetworks.com:
Hi python devs :
As a part of exploring an idea, I am trying to add a new method to the
python socket object. Here's what I have been trying to do (the patch may
be whitespace damaged so please bear with me) :
Index: Python-2.7/Modules/socketmodule.c
===
--- Python-2.7.orig/Modules/socketmodule.c
+++ Python-2.7/Modules/socketmodule.c
@@ -126,6 +126,7 @@ makefile([mode, [bufsize]]) -- return a
recv(buflen[, flags]) -- receive data\n\
recv_into(buffer[, nbytes[, flags]]) -- receive data (into a buffer)\n\
recvfrom(buflen[, flags]) -- receive data and sender\'s address\n\
+arecvfrom(buflen[, flags]) -- same as recvfrom \n\
recvfrom_into(buffer[, nbytes, [, flags])\n\
-- receive data and sender\'s address (into a buffer)\n\
sendall(data[, flags]) -- send all data\n\
@@ -468,6 +469,13 @@ static PyTypeObject sock_type;
#define IS_SELECTABLE(s) ((s)-sock_fd FD_SETSIZE || s-sock_timeout =
0.0)
#endif
@@ -2620,6 +2802,58 @@ PyDoc_STRVAR(recvfrom_doc,
\n\
Like recv(buffersize, flags) but also return the sender's address info.);
+static PyObject *
+sock_arecvfrom(PySocketSockObject *s, PyObject *args)
+{
+return sock_recvfrom(s,args);
+}
+
+PyDoc_STRVAR(arecvfrom_doc,
+arecvfrom(buffersize[, flags]) - (data, address info)\n\
+\n\
+ experimental stuff);
/* s.recvfrom_into(buffer[, nbytes [,flags]]) method */
@@ -2963,6 +3197,8 @@ static PyMethodDef sock_methods[] = {
recv_into_doc},
{recvfrom, (PyCFunction)sock_recvfrom, METH_VARARGS,
recvfrom_doc},
+{arecvfrom, (PyCFunction)sock_arecvfrom, METH_VARARGS,
+ arecvfrom_doc},
{recvfrom_into, (PyCFunction)sock_recvfrom_into, METH_VARARGS |
METH_KEYWORDS,
recvfrom_into_doc},
{send, (PyCFunction)sock_send, METH_VARARGS,
When I compile this and run a simple script like the following that uses
arecvfrom() :
sock = socket.socket( socket.PF_PACKET, socket.SOCK_RAW )
sock.bind( ( intf, ETH_P_ALL ) )
(pkt,dontcare) = dst.arecvfrom( 500, socket.MSG_DONTWAIT )
I get this exception :
AttributeError: '_socketobject' object has no attribute 'arecvfrom'
So what am I doing wrong? How do I export this new socket method?
any help/pointer will be greatly appreciated.
cheers,
ani
--
Ani
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/python.00%40klix.ch
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] stat module in C -- what to do with stat.py?
On 21 June 2013 21:45, Antoine Pitrou solip...@pitrou.net wrote: Le Fri, 21 Jun 2013 21:39:10 +1000, Nick Coghlan ncogh...@gmail.com a écrit : What's not OK is for the standard library to regress for other implementations just because we added a C implementation for the benefit of CPython. That's exactly the kind of thing PEP 399 says we *won't* do. For me, PEP 399 should not be considered a requirement but a guideline. stat.py is algorithmically trivial and I don't think it saves much work for authors of third-party Python implementations. So why not just replace the *broken* parts of stat.py and keep the rest of it? Why make pointless work for the other implementations? Basically, I want to hear from the Jython, PyPy and IronPython devs that they're OK with us deleting Lib/stat.py. Hearing other CPython devs say they're fine with it doesn't mean anything, since we're not the ones that will have to do additional work as a result. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] stat module in C -- what to do with stat.py?
Le Sat, 22 Jun 2013 01:29:40 +1000, Nick Coghlan ncogh...@gmail.com a écrit : On 21 June 2013 21:45, Antoine Pitrou solip...@pitrou.net wrote: Le Fri, 21 Jun 2013 21:39:10 +1000, Nick Coghlan ncogh...@gmail.com a écrit : What's not OK is for the standard library to regress for other implementations just because we added a C implementation for the benefit of CPython. That's exactly the kind of thing PEP 399 says we *won't* do. For me, PEP 399 should not be considered a requirement but a guideline. stat.py is algorithmically trivial and I don't think it saves much work for authors of third-party Python implementations. So why not just replace the *broken* parts of stat.py and keep the rest of it? Why make pointless work for the other implementations? I guess the answer is: because it's more work for us :-) Basically, I want to hear from the Jython, PyPy and IronPython devs that they're OK with us deleting Lib/stat.py. Hearing other CPython devs say they're fine with it doesn't mean anything, since we're not the ones that will have to do additional work as a result. Yes, I agree with that. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] stat module in C -- what to do with stat.py?
2013/6/21 Nick Coghlan ncogh...@gmail.com: Basically, I want to hear from the Jython, PyPy and IronPython devs that they're OK with us deleting Lib/stat.py. Hearing other CPython devs say they're fine with it doesn't mean anything, since we're not the ones that will have to do additional work as a result. hat kind=pypy Kill it. I would argue having incorrect constants makes the implementation incompatible with CPython anyway. This not that much work (as long as there are tests that the constants exist at least) to emulate. /hat -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2013-06-14 - 2013-06-21) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open4057 (+15) closed 25993 (+47) total 30050 (+62) Open issues with patches: 1804 Issues opened (42) == #18113: Memory leak in curses.panel http://bugs.python.org/issue18113 reopened by serhiy.storchaka #18216: gettext doesn't check MO versions http://bugs.python.org/issue18216 opened by jwilk #18217: Deprecate and remove gettext.install http://bugs.python.org/issue18217 opened by alex #18219: csv.DictWriter is slow when writing files with large number of http://bugs.python.org/issue18219 opened by mtraskin #18220: In itertools.islice() make prototype like in help() http://bugs.python.org/issue18220 opened by py.user #18221: abspath strips trailing spaces on win32 http://bugs.python.org/issue18221 opened by Jeremy.Gray #18222: os.path.abspath should accept multiple path parts and join the http://bugs.python.org/issue18222 opened by Åukasz.Balcerzak #18224: pyvenv pydoc.py script causing AttributeErrors on Windows http://bugs.python.org/issue18224 opened by pe...@psantoro.net #18226: IDLE Unit test for FormatParagrah.py http://bugs.python.org/issue18226 opened by Todd.Rovito #18227: Use Python memory allocators in external libraries like zlib o http://bugs.python.org/issue18227 opened by haypo #18228: AIX locale parsing failure http://bugs.python.org/issue18228 opened by David.Edelsohn #18229: attribute headers of http.server.BaseHTTPRequestHandler someti http://bugs.python.org/issue18229 opened by joru #18230: test_builtin fails/hangs when run after test_getopt http://bugs.python.org/issue18230 opened by brett.cannon #18231: What's new in Python should explain what's new in UCD http://bugs.python.org/issue18231 opened by belopolsky #18232: running a suite with no tests is not an error http://bugs.python.org/issue18232 opened by rbcollins #18233: SSLSocket.getpeercertchain() http://bugs.python.org/issue18233 opened by christian.heimes #18234: Unicodedata module should provide access to codepoint aliases http://bugs.python.org/issue18234 opened by belopolsky #18235: _sysconfigdata.py wrong on AIX installations http://bugs.python.org/issue18235 opened by David.Edelsohn #18236: int() and float() do not accept strings with trailing separato http://bugs.python.org/issue18236 opened by belopolsky #18237: unittest.assertRaisesRegex(p) example is wrong in docs http://bugs.python.org/issue18237 opened by jtratner #18240: hmac unnecessarily restricts input to bytes http://bugs.python.org/issue18240 opened by jborgstrom #18241: Add unique option to heapq functions http://bugs.python.org/issue18241 opened by pitrou #18242: IDLE should not be replacing warnings.formatwarning http://bugs.python.org/issue18242 opened by brett.cannon #18243: mktime_tz documentation out-of-date http://bugs.python.org/issue18243 opened by jwilk #18244: singledispatch: When virtual-inheriting ABCs at distinct point http://bugs.python.org/issue18244 opened by ecatmur #18246: tkinter.Text() add a newline to the content - bug? http://bugs.python.org/issue18246 opened by Friedrich.Spee.von.Langenfeld #18249: Incorrect and incomplete help docs for close() method http://bugs.python.org/issue18249 opened by DaveA #18254: Accessing attr dict at definition time of a class from a metac http://bugs.python.org/issue18254 opened by archardlias #18255: CPython setup.py problems http://bugs.python.org/issue18255 opened by ronaldoussoren #18257: Two copies of python-config http://bugs.python.org/issue18257 opened by ronaldoussoren #18258: Fix test discovery for test_codecmaps*.py http://bugs.python.org/issue18258 opened by zach.ware #18260: configparser: TypeError occurs when handling errors in files w http://bugs.python.org/issue18260 opened by Arfrever #18262: ZipInfo.external_attr are not documented http://bugs.python.org/issue18262 opened by techtonik #18264: enum.IntEnum is not compatible with JSON serialisation http://bugs.python.org/issue18264 opened by ncoghlan #18266: Fix test discovery for test_largefile.py http://bugs.python.org/issue18266 opened by zach.ware #18268: ElementTree.fromstring non-deterministically gives unicode tex http://bugs.python.org/issue18268 opened by Brendan.OConnor #18269: Add new parameter format for converter function w/ position nu http://bugs.python.org/issue18269 opened by techtonik #18270: IDLE on OS X fails with Attribute Error if no initial shell an http://bugs.python.org/issue18270 opened by dbackhaus #18273: Simplify calling and discovery of json test package http://bugs.python.org/issue18273 opened by zach.ware #18275: Make isinstance() work with super type instances http://bugs.python.org/issue18275 opened by brett.cannon #18276: posixpath.c:_fd_converter() should use
Re: [Python-Dev] stat module in C -- what to do with stat.py?
On 6/21/2013 7:45 AM, Antoine Pitrou wrote: Le Fri, 21 Jun 2013 21:39:10 +1000, Nick Coghlan ncogh...@gmail.com a écrit : I think it's OK to expose additional platform specific features in the C version, and have them fail cleanly with the pure Python version (rather than silently giving the wrong answer). PEP 399 says we don't do it: Acting as a drop-in replacement also dictates that no public API be provided in accelerated code that does not exist in the pure Python code. Without this requirement people could accidentally come to rely on a detail in the accelerated code which is not made available to other VMs that use the pure Python implementation. Any C accelerator extensions should by documented as CPython extensions not necessarily available elsewhere. Or the doc should have, in this case, a separate _stat that says In addition to the above, CPython's _stat, imported by stat, also provides ... -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] stat module in C -- what to do with stat.py?
Am 21.06.2013 17:47, schrieb Benjamin Peterson: hat kind=pypy Kill it. I would argue having incorrect constants makes the implementation incompatible with CPython anyway. This not that much work (as long as there are tests that the constants exist at least) to emulate. /hat My patch adds extensive tests for all features of the stat module. The test check the existence of attributes and the return value of all functions. A missing or ill-defined attribute is going to raise an error. But see for yourself: http://hg.python.org/cpython/rev/f8ff61f44aca Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 445 delegate
Hello, I've been appointed PEP 445 delegate by Nick and Guido. I would like to know if there are still pending changes to the PEP. If not, I expect to give it a review in the coming days or weeks, and then make a final pronouncement (which will probably be positive anyway). Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [python 2.7] a question about exporting a new method to socket object
Hi Guido :
Thanks a lot. That helped.
I will try StackOverflow next time.
cheers,
ani
On Fri, Jun 21, 2013 at 8:07 AM, Guido van Rossum gu...@python.org wrote:
Technically this list isn't the right place, but you probably are
bitten by the duplication of functionality in Lib/socket.py. There's a
list of methods at the top of that file, _socketmethods.
But you really shouldn't be asking here -- this list is for changes to
Python, not using or hacking it. (Try StackOverflow for that.)
--Guido
On Thu, Jun 20, 2013 at 10:18 PM, Ani Sinha a...@aristanetworks.com
wrote:
Hi python devs :
As a part of exploring an idea, I am trying to add a new method to the
python socket object. Here's what I have been trying to do (the patch
may be
whitespace damaged so please bear with me) :
Index: Python-2.7/Modules/socketmodule.c
===
--- Python-2.7.orig/Modules/socketmodule.c
+++ Python-2.7/Modules/socketmodule.c
@@ -126,6 +126,7 @@ makefile([mode, [bufsize]]) -- return a
recv(buflen[, flags]) -- receive data\n\
recv_into(buffer[, nbytes[, flags]]) -- receive data (into a buffer)\n\
recvfrom(buflen[, flags]) -- receive data and sender\'s address\n\
+arecvfrom(buflen[, flags]) -- same as recvfrom \n\
recvfrom_into(buffer[, nbytes, [, flags])\n\
-- receive data and sender\'s address (into a buffer)\n\
sendall(data[, flags]) -- send all data\n\
@@ -468,6 +469,13 @@ static PyTypeObject sock_type;
#define IS_SELECTABLE(s) ((s)-sock_fd FD_SETSIZE || s-sock_timeout
=
0.0)
#endif
@@ -2620,6 +2802,58 @@ PyDoc_STRVAR(recvfrom_doc,
\n\
Like recv(buffersize, flags) but also return the sender's address
info.);
+static PyObject *
+sock_arecvfrom(PySocketSockObject *s, PyObject *args)
+{
+return sock_recvfrom(s,args);
+}
+
+PyDoc_STRVAR(arecvfrom_doc,
+arecvfrom(buffersize[, flags]) - (data, address info)\n\
+\n\
+ experimental stuff);
/* s.recvfrom_into(buffer[, nbytes [,flags]]) method */
@@ -2963,6 +3197,8 @@ static PyMethodDef sock_methods[] = {
recv_into_doc},
{recvfrom, (PyCFunction)sock_recvfrom, METH_VARARGS,
recvfrom_doc},
+{arecvfrom, (PyCFunction)sock_arecvfrom, METH_VARARGS,
+ arecvfrom_doc},
{recvfrom_into, (PyCFunction)sock_recvfrom_into, METH_VARARGS |
METH_KEYWORDS,
recvfrom_into_doc},
{send, (PyCFunction)sock_send, METH_VARARGS,
When I compile this and run a simple script like the following that uses
arecvfrom() :
sock = socket.socket( socket.PF_PACKET, socket.SOCK_RAW )
sock.bind( ( intf, ETH_P_ALL ) )
(pkt,dontcare) = dst.arecvfrom( 500, socket.MSG_DONTWAIT )
I get this exception :
AttributeError: '_socketobject' object has no attribute 'arecvfrom'
So what am I doing wrong? How do I export this new socket method?
any help/pointer will be greatly appreciated.
cheers,
ani
--
Ani
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (python.org/~guido)
--
Ani
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] stat module in C -- what to do with stat.py?
On 22/06/13 01:29, Nick Coghlan wrote: Basically, I want to hear from the Jython, PyPy and IronPython devs that they're OK with us deleting Lib/stat.py. Hearing other CPython devs say they're fine with it doesn't mean anything, since we're not the ones that will have to do additional work as a result. It's not just established Python implementations. A pure-python standard library makes a good foundation for any future implementations. -- Steven ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] stat module in C -- what to do with stat.py?
On 21/06/13 01:35, Benjamin Peterson wrote: 2013/6/20 Charles-François Natali cf.nat...@gmail.com: 2013/6/20 Thomas Wouters tho...@python.org: If the .py file is going to be wrong or incomplete, why would we want to keep it -- or use it as fallback -- at all? If we're dead set on having a .py file instead of requiring it to be part of the interpreter (whichever that is, however it was built), it should be generated as part of the build process. Personally, I don't see the value in it; other implementations will need to do *something* special to use it anyway. That's not correct. Other implementations can do exactly what CPython 3.3 does, namely just use stat.py as given. Not all implementations necessarily care about multiple platforms where stat constants are likely to change. That's exactly my rationale for pushing for removal. +1 to nixing it. -1 Reading the Python source code is a very good way for beginner programmers to learn about things like this. Being able to read stat.py in Python makes a good, complementary source of information for those new to stat. Getting rid of stat.py means there's no source code to read at all, unless the user has built Python from source and kept the C source code. And even if they have, it's easy to forget how intimidating C can be to neophytes. I'm with Nick on this one: PEP 399 already answers the question of what to do with stat.py. We keep it as a fallback, which guarantees that any Python implementation that uses the standard library is no worse off than what we have now. When available, we override the default constants with platform specific ones generated from whatever language is used by the implementation. The accuracy of those constants then becomes a matter of quality of implementation. A low quality implementation may take the lazy way out and just use the default constants, while a high quality implementation will not. At the moment, the stat.py module contains ten small functions. Getting rid of the stat.py means that they have to be re-implemented in C/Java/RPython/etc. for every implementation. Even if the re-implementations are individually trivial, it's still a cost for no real gain. Keeping the pure Python implementation also lowers the bar for adding new functions in the future, and for documentation changes. -- Steven ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] stat module in C -- what to do with stat.py?
On Fri, Jun 21, 2013 at 9:29 AM, Nick Coghlan ncogh...@gmail.com wrote: So why not just replace the *broken* parts of stat.py and keep the rest of it? In some ways this sounds like yet another use case for what amounts to properties on modules. The sketchy contants that are causing concern could raise NotImplementedError in stat.py, but the C version would implement them. Then PEP 399 remains satisfied and appropriately so. -eric ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 445 delegate
Hi, 2013/6/21 Antoine Pitrou solip...@pitrou.net: I've been appointed PEP 445 delegate by Nick and Guido. I would like to know if there are still pending changes to the PEP. Cool. Hum, there is maybe something. In my pytracemalloc project, I added another API to track usage of free lists: PyAPI_FUNC(int) _PyFreeList_SetAllocators( void (*alloc) (PyObject *), void (*free) (PyObject *) ); PyAPI_FUNC(void) _PyFreeList_Alloc(void *); PyAPI_FUNC(void) _PyFreeList_Free(void *); Then I'm using Py_TYPE(op)-tp_basicsize to get the size of the object. I didn't add this API to the PEP because I'm not really convinced that is useful. I wrote it becase Python 2 has unlimited free lists, especially for the int type. In Python 3, the situation is different: free lists have a limited size, and the int type of Python 3 is the old long type, and int in Python 3 does not use a free list. (By the way, it may provide better performances if we had a free list for small ints.) I expect better results with the new PyMem_RawMalloc() function and the Don't call malloc() directly anymore section of the PEP than with tracking free lists. I'm testing Python 3.4 with all patches related to the PEP 445 (#3329, #16742, #18203) and it works fine. You can also try my pytracemalloc project with its userdata branch. I just found a bug in pytracemalloc for allocation of zero bytes :-) Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] stat module in C -- what to do with stat.py?
On Fri, Jun 21, 2013 at 8:20 PM, Steven D'Aprano st...@pearwood.infowrote: On 21/06/13 01:35, Benjamin Peterson wrote: 2013/6/20 Charles-François Natali cf.nat...@gmail.com: 2013/6/20 Thomas Wouters tho...@python.org: If the .py file is going to be wrong or incomplete, why would we want to keep it -- or use it as fallback -- at all? If we're dead set on having a .py file instead of requiring it to be part of the interpreter (whichever that is, however it was built), it should be generated as part of the build process. Personally, I don't see the value in it; other implementations will need to do *something* special to use it anyway. That's not correct. Other implementations can do exactly what CPython 3.3 does, namely just use stat.py as given. Not all implementations necessarily care about multiple platforms where stat constants are likely to change. That's exactly my rationale for pushing for removal. +1 to nixing it. -1 Reading the Python source code is a very good way for beginner programmers to learn about things like this. On the other hand, it is counter-productive to learn about code that is conceptually _wrong_. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] stat module in C -- what to do with stat.py?
On 21Jun2013 21:39, Nick Coghlan ncogh...@gmail.com wrote: | On 21 June 2013 17:25, Victor Stinner victor.stin...@gmail.com wrote: | How do you plan to handle the following case in Python? | | Looking in more detail: for the S_IFMT flags, OSX/Darwin/FreeBSD defines | 0xe000 as S_IFWHT (whiteout), but Solaris defines it as | S_IFPORT (event port). | | We may keep the Python module if it is kept unchanged, but the Python | and C modules should have the same public API (the C module should not | have more features). | | I think it's OK to expose additional platform specific features in the | C version, and have them fail cleanly with the pure Python version | (rather than silently giving the wrong answer). What's not OK is for | the standard library to regress for other implementations just because | we added a C implementation for the benefit of CPython. That's exactly | the kind of thing PEP 399 says we *won't* do. +1 I'm all for the C module exposing any and all of the S_* macros for the local platform, and good with the python module (if used because the C module isn't present, or conceivably is compiled out because it is known broken on this platform) exposing only the portable stuff. At least you can detect I don't know what to do rather than ploughing on mistakenly. -- Cameron Simpson c...@zip.com.au Ignorance is preferable to error; and he is less remote from the truth who believes nothing, than he who believes what is wrong. - Thomas Jefferson ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] stat module in C -- what to do with stat.py?
Gustavo Carneiro writes: On Fri, Jun 21, 2013 at 8:20 PM, Steven D'Aprano st...@pearwood.info wrote: -1 Reading the Python source code is a very good way for beginner programmers to learn about things like this. On the other hand, it is counter-productive to learn about code that is conceptually _wrong_. It's hardly _conceptually_ wrong when it's simply a pure-Python version that reflects *exactly* the implementation used by many OSes written in C. It's purely a quality of implementation issue in that it fails to observe the DRY principle and is non-portable. But if you look at sys/stat.h on Mac OS X or Linux, you'll see that the visible definitions are protected by a thicket of #ifdefs, and the actual definitions may be drawn from other files #include'd there, and not using the definitions visible in sys/stat.h at all. Ie, on those systems the OS implementation possesses exactly the same structure that CPython would have with a stat.py + _stat module implementation. If the presence of the _stat module is documented and the rationale briefly explained in stat.py, I suppose you have the best of both worlds for the novice programmer (at the expense of a test for the presence of _stat at import time). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] stat module in C -- what to do with stat.py?
On 20Jun2013 08:35, Benjamin Peterson benja...@python.org wrote: | 2013/6/20 Charles-François Natali cf.nat...@gmail.com: | 2013/6/20 Thomas Wouters tho...@python.org: | If the .py file is going to be wrong or incomplete, why would we want to | keep it -- or use it as fallback -- at all? If we're dead set on having a | .py file instead of requiring it to be part of the interpreter (whichever | that is, however it was built), it should be generated as part of the build | process. Personally, I don't see the value in it; other implementations will | need to do *something* special to use it anyway. | | That's exactly my rationale for pushing for removal. | | +1 to nixing it. -1 to nixing it. I think there should be a pure python reference implementation. If it exposes only the portable constants/macros or, better, has a machine generated _section_ for the local platform macros, all to the good; it would not lie. - A huge amount of code only needs to care about the portable stuff (is this a dir, is this a regular file, is it neither). Missing local constants won't break such code. - A reference implementation exposes algorithms and purpose in a common language (Python, of course; everyone caring about such an impl can already read Python:-). - A reference implementation provides a base for other implementations to use outright, or to build on. - A reference implementation provides something to test against for comparison of the common stuff. - The implementation cost is low; the ref implementation already exists! Getting rid of it seems mad. Pruning/fixing/adapting the nonportable bits might be good. Christian Heimes' test patch would make that much easier to identify. So, -1 on removal of stat.py. Cheers, -- Cameron Simpson c...@zip.com.au I will not do it as a hack I will not do it for my friends I will not do it on a MacI will not write for Uncle Sam I will not do it on weekends I won't do ADA, Sam-I-Am - Gregory Bond g...@bby.com.au ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
