[issue34057] Py_Initialize aborts when using static Python version. Windows
New submission from Alberto : Hi, I've followed the build instructions to get a statically linked Python library in windows. The compilation works great and I get a big fat statically linked .lib file. When I use it and in my code I call Py_Initialize() the program aborts and I get this error: Fatal Python error: initfsencoding: unable to load the file system codec ModuleNotFoundError: No module named 'encodings' It seems that python is looking for encodings on the file system instead of looking for the built-in one since if I do Py_SetPythonHome(L"C:\\Python37.0-x64"); before calling Py_Initialize it works fine. Why is Python looking for external modules when it is a statically linked library and encodings should be built-in? How can I indicate Python to look for the modules in itself and not externally? Regards -- components: Interpreter Core messages: 321140 nosy: illera88 priority: normal severity: normal status: open title: Py_Initialize aborts when using static Python version. Windows type: crash versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue34057> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34057] Py_Initialize aborts when using static Python version. Windows
Alberto added the comment: Hi, First of all thank you for your answer. If every module can't be statically compiled within a library, what is the point of having instructions to compile python statically in the build instructions? Can I modify the code to make it completely statically? Thank you On Fri, Jul 6, 2018 at 12:27 AM STINNER Victor wrote: > > STINNER Victor added the comment: > > > Why is Python looking for external modules when it is a statically > linked library and encodings should be built-in? > > Hi, this is not a bug. Python needs its standard library. You might want > to put the whole stdlib into a single ZIP, but I don't recall how to do > that. > > The encodings and codecs modules are not built-in, but _codecs is built-in: > > >>> import encodings, codecs, _codecs > >>> encodings > > >>> codecs > > >>> _codecs > > > I suggest to close this issue as "not a bug". You should ask on a Python > mailing list or forum to get help how to build a standalone Python. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue34057> > ___ > -- Alberto García Illera GPG Public Key: https://goo.gl/twKUUv -- ___ Python tracker <https://bugs.python.org/issue34057> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34057] Py_Initialize aborts when using static Python version. Windows
Alberto added the comment: Hey Victor, I've spent another number of hours debugging the problem and trying to avoid encodings to be loaded but I've had no luck since initfsencoding is necesary for init_sys_streams to work and that's an important function that sets stdin, stout and sterr. It seems that encodings is the only thing that prevents Py_Initialize to be called and therefore for a static python version to be used. Is there any way to move encodings to pythoncore? Is there any other solution? I'm happy to put my time on this (I've already spent 3 full days debugging the problem). I think this could be considered a bug since there is no point on statically build python and use it as a library as the README stands if there is still requirements on encodings which need to reside on the filesystem. Thank you again for your time -- ___ Python tracker <https://bugs.python.org/issue34057> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34252] Bunch of path leaks on Python 3.7 on Release
New submission from Alberto : I've downloaded and compiled from sources Python 3.7 in windows. The compilation process goes great but there are a lot of paths (using __FILE__ in the source) that gets leaked in the Release version and that should not happen. This is because __FILE__ is used outside of assert or DEBUG ifdefs which should be avoided. Here is the list I've got after doing a strings on a build release: c:\users\mysupersecretuser\downloads\python-3.7.0_\objects\typeobject.c c:\users\mysupersecretuser\downloads\python-3.7.0_\python\import.c c:\users\mysupersecretuser\downloads\python-3.7.0_\objects\moduleobject.c c:\users\mysupersecretuser\downloads\python-3.7.0_\objects\longobject.c c:\users\mysupersecretuser\downloads\python-3.7.0_\python\getargs.c c:\users\mysupersecretuser\downloads\python-3.7.0_\objects\frameobject.c c:\users\mysupersecretuser\downloads\python-3.7.0_\modules\gcmodule.c c:\users\mysupersecretuser\downloads\python-3.7.0_\objects\object.c c:\users\mysupersecretuser\downloads\python-3.7.0_\objects\listobject.c c:\users\mysupersecretuser\downloads\python-3.7.0_\objects\fileobject.c c:\users\mysupersecretuser\downloads\python-3.7.0_\objects\dictobject.c c:\users\mysupersecretuser\downloads\python-3.7.0_\python\traceback.c c:\users\mysupersecretuser\downloads\python-3.7.0_\objects\tupleobject.c c:\users\mysupersecretuser\downloads\python-3.7.0_\objects\classobject.c c:\users\mysupersecretuser\downloads\python-3.7.0_\objects\unicodeobject.c c:\users\mysupersecretuser\downloads\python-3.7.0_\objects\bytearrayobject.c c:\users\mysupersecretuser\downloads\python-3.7.0_\objects\setobject.c c:\users\mysupersecretuser\downloads\python-3.7.0_\objects\bytesobject.c c:\users\mysupersecretuser\downloads\python-3.7.0_\objects\weakrefobject.c c:\users\mysupersecretuser\downloads\python-3.7.0_\objects\cellobject.c c:\users\mysupersecretuser\downloads\python-3.7.0_\objects\iterobject.c c:\users\mysupersecretuser\downloads\python-3.7.0_\objects\codeobject.c c:\users\mysupersecretuser\downloads\python-3.7.0_\python\ast.c c:\users\mysupersecretuser\downloads\python-3.7.0_\python\pystrtod.c c:\users\mysupersecretuser\downloads\python-3.7.0_\modules\_asynciomodule.c c:\users\mysupersecretuser\downloads\python-3.7.0_\modules\arraymodule.c c:\users\mysupersecretuser\downloads\python-3.7.0_\modules\_sha3\sha3module.c c:\users\mysupersecretuser\downloads\python-3.7.0_\modules\parsermodule.c c:\users\mysupersecretuser\downloads\python-3.7.0_\modules\zipimport.c FFI_TRAMPOLINE_SIZE too small in c:\users\mysupersecretuser\downloads\python-3.7.0_\modules\_ctypes\libffi_msvc\ffi.c c:\users\mysupersecretuser\downloads\python-3.7.0_\modules\_decimal\libmpdec\typearith.h c:\users\mysupersecretuser\downloads\python-3.7.0_\modules\_decimal\libmpdec\mpdecimal.c c:\users\mysupersecretuser\downloads\python-3.7.0_\modules\_decimal\libmpdec\context.c c:\users\mysupersecretuser\downloads\python-3.7.0_\modules\_ssl.c c:\users\mysupersecretuser\downloads\python-3.7.0_\modules\pyexpat.c -- components: Build messages: 322512 nosy: illera88 priority: normal severity: normal status: open title: Bunch of path leaks on Python 3.7 on Release type: enhancement versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue34252> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34252] Bunch of path leaks on Python 3.7 on Release
Alberto added the comment: In Visual Studio /FP should be removed: In C/C++ → Advanced → Use Full Paths: No But still for some weird reason there is one path that gets leaked: c:\users\mysupersecretuser\downloads\python-3.7.0_\modules\_decimal\libmpdec\typearith.h In the project from where I'm using python I already removed /FP so even if it is a header it should not be showing the full path AFAIK. Any idea? -- ___ Python tracker <https://bugs.python.org/issue34252> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8739] Update to smtpd.py to RFC 5321
Alberto Trevino added the comment: Any more work I need to do on this patch? -- ___ Python tracker <http://bugs.python.org/issue8739> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9168] setuid in smtp.py sheds privileges before binding port
Alberto Trevino added the comment: I haven't heard anything on this problem or my patch. What's the status? -- ___ Python tracker <http://bugs.python.org/issue9168> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8739] Update to smtpd.py to RFC 5321
Alberto Trevino added the comment: On Sunday, August 15, 2010 09:19:27 am Giampaolo Rodola' wrote: > Patch no longer applies cleanly because smtpd.py changed in the meantime. Is someone going to fix that or I am expected to play daily catch-up until this gets merged? > A further comment: > > -def __init__(self, server, conn, addr): > +def __init__(self, server, conn, addr, size = 0): > -def __init__(self, localaddr, remoteaddr): > +def __init__(self, localaddr, remoteaddr, size = 0): > > This change breaks backward compatibility. I think it would be better to > provide this as a SMTPChannel.size_limit class attribute. Unfortunately, I don't have the time in the next few weeks to make that change. Can someone else make it? -- ___ Python tracker <http://bugs.python.org/issue8739> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8739] Update to smtpd.py to RFC 5321
Alberto Trevino added the comment: On Monday, August 16, 2010 11:42:51 am you wrote: > Re-adapted patch including size_limit change as described in my previous > message is in attachment. Barry and Alberto, could you take a final look > at it before committing? Looks good to me. If the tests pass, then I'm good to go. -- ___ Python tracker <http://bugs.python.org/issue8739> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8739] Update to smtpd.py to RFC 5321
Alberto Trevino added the comment: On Monday, August 16, 2010 12:58:07 pm Barry A. Warsaw wrote: > The one thing that looks weird to me is VRFY. Since it never actually > does verify the user, should we even claim to support the command? Why > not let subclasses claim support if they want to add it? RFC 5321 section 4.5.1 states VRFY should be implemented in order to be considered an RFC 5321-compliant implementation. But, in section 3.5.3 paragraph 2 it states that if the actual verification was not performed but syntax was checked similar to RCPT, then the response code should be 252. So my purposes for providing the plumbing for VRFY are: 1. Provide a basic, valid implementation to be as RFC 5321-compliant as possible. 2. Let users know the command is there so that it can be reimplemented as they build their solutions. -- ___ Python tracker <http://bugs.python.org/issue8739> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1644] Patch submission guidelines outdated
New submission from Alberto Bertogli:
The FAQ section 5.4, "How to submit a patch?", points to
http://www.python.org/patches/, which looks really outdated
(plus the sf page seems to be restricted to members only).
Thanks,
Alberto
--
components: Documentation
messages: 58719
nosy: albertito
severity: normal
status: open
title: Patch submission guidelines outdated
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1644>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1645] Fix socketmodule.c:sock_recvfrom_guts() comment.
New submission from Alberto Bertogli: The comment above sock_recvfrom_guts() was copied from sock_recv_guts() and referenced recv() and recv_into() when it should be talking about recvfrom() and recvfrom_into(). The attached patch (against trunk) fixes it. -- components: Library (Lib) files: 0001-Fix-socketmodule.c-sock_recvfrom_guts-comment.patch messages: 58720 nosy: albertito severity: minor status: open title: Fix socketmodule.c:sock_recvfrom_guts() comment. versions: Python 2.6 Added file: http://bugs.python.org/file8980/0001-Fix-socketmodule.c-sock_recvfrom_guts-comment.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1645> __From: Alberto Bertogli <[EMAIL PROTECTED]> Date: Wed, 5 Dec 2007 15:53:35 -0300 Subject: [PATCH] Fix socketmodule.c:sock_recvfrom_guts() comment. The comment above sock_recvfrom_guts() was copied from sock_recv_guts() and referenced recv() and recv_into() when it should be talking about recvfrom() and recvfrom_into(). --- Modules/socketmodule.c | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c --- a/Modules/socketmodule.c +++ b/Modules/socketmodule.c @@ -2358,12 +2358,12 @@ See recv() for documentation about the flags."); /* - * This is the guts of the recv() and recv_into() methods, which reads into a - * char buffer. If you have any inc/def ref to do to the objects that contain - * the buffer, do it in the caller. This function returns the number of bytes - * succesfully read. If there was an error, it returns -1. Note that it is - * also possible that we return a number of bytes smaller than the request - * bytes. + * This is the guts of the recvfrom() and recvfrom_into() methods, which reads + * into a char buffer. If you have any inc/def ref to do to the objects that + * contain the buffer, do it in the caller. This function returns the number + * of bytes succesfully read. If there was an error, it returns -1. Note + * that it is also possible that we return a number of bytes smaller than the + * request bytes. * * 'addr' is a return value for the address object. Note that you must decref * it yourself. -- 1.5.4.rc0.1096.gcd2a6 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1646] Make socket support TIPC.
New submission from Alberto Bertogli:
TIPC (http://tipc.sf.net) is an open protocol designed for use in
clustered computer environments. It currently has an open source
implementation for Linux (>= 2.6.16), and VxWorks.
The attached patch (against trunk) adds optional Linux-only support for
TIPC in the socket module.
If you want me to make one against 3.0 or any other branch, just let me
know.
Thanks,
Alberto
--
components: Library (Lib)
files: 0002-Make-socket-support-TIPC.patch
messages: 58721
nosy: albertito
severity: normal
status: open
title: Make socket support TIPC.
versions: Python 2.6
Added file: http://bugs.python.org/file8981/0002-Make-socket-support-TIPC.patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1646>
______From: Alberto Bertogli <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 18:39:18 -0300
Subject: [PATCH] Make socket support TIPC.
TIPC (http://tipc.sf.net) is an open protocol designed for use in
clustered computer environments. It currently has an open source
implementation for Linux (>= 2.6.16), and VxWorks.
This patch adds optional Linux-only support for TIPC in the socket module.
---
Modules/socketmodule.c | 154 +++-
Modules/socketmodule.h |4 +
configure.in |2 +-
3 files changed, 158 insertions(+), 2 deletions(-)
diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c
--- a/Modules/socketmodule.c
+++ b/Modules/socketmodule.c
@@ -7,7 +7,8 @@ This module provides an interface to Berkeley socket IPC.
Limitations:
- Only AF_INET, AF_INET6 and AF_UNIX address families are supported in a
- portable manner, though AF_PACKET and AF_NETLINK are supported under Linux.
+ portable manner, though AF_PACKET, AF_NETLINK and AF_TIPC are supported
+ under Linux.
- No read/write operations (use sendall/recv or makefile instead).
- Additional restrictions apply on some non-Unix platforms (compensated
for by socket.py).
@@ -52,6 +53,25 @@ Module interface:
the Ethernet protocol number to be received. For example:
("eth0",0x1234). Optional 3rd,4th,5th elements in the tuple
specify packet-type and ha-type/addr.
+- an AF_TIPC socket address is expressed as
+ (addr_type, v1, v2, v3 [, scope]); where addr_type can be one of:
+ TIPC_ADDR_NAMESEQ, TIPC_ADDR_NAME, and TIPC_ADDR_ID;
+ and scope can be one of:
+ TIPC_ZONE_SCOPE, TIPC_CLUSTER_SCOPE, and TIPC_NODE_SCOPE.
+ The meaning of v1, v2 and v3 depends on the value of addr_type:
+ if addr_type is TIPC_ADDR_NAME:
+ v1 is the server type
+ v2 is the port identifier
+ v3 is ignored
+ if addr_type is TIPC_ADDR_NAMESEQ:
+ v1 is the server type
+ v2 is the lower port number
+ v3 is the upper port number
+ if addr_type is TIPC_ADDR_ID:
+ v1 is the node
+ v2 is the ref
+ v3 is ignored
+
Local naming conventions:
@@ -1094,6 +1114,39 @@ makesockaddr(int sockfd, struct sockaddr *addr, int addrlen, int proto)
}
#endif
+#ifdef HAVE_LINUX_TIPC_H
+ case AF_TIPC:
+ {
+ struct sockaddr_tipc *a = (struct sockaddr_tipc *) addr;
+ if (a->addrtype == TIPC_ADDR_NAMESEQ) {
+ return Py_BuildValue("I",
+ a->addrtype,
+ a->addr.nameseq.type,
+ a->addr.nameseq.lower,
+ a->addr.nameseq.upper,
+ a->scope);
+ } else if (a->addrtype == TIPC_ADDR_NAME) {
+ return Py_BuildValue("I",
+ a->addrtype,
+ a->addr.name.name.type,
+ a->addr.name.name.instance,
+ a->addr.name.name.instance,
+ a->scope);
+ } else if (a->addrtype == TIPC_ADDR_ID) {
+ return Py_BuildValue("I",
+ a->addrtype,
+ a->addr.id.node,
+ a->addr.id.ref,
+ 0,
+ a->scope);
+ } else {
+ PyErr_SetString(PyExc_TypeError,
+ "Invalid address type");
+ return NULL;
+ }
+ }
+#endif
+
/* More cases here... */
default:
@@ -1379,6 +1432,56 @@ getsockaddrarg(PySocketSockObject *s, PyObject *args,
}
#endif
+#ifdef HAVE_LINUX_TIPC_H
+ case AF_TIPC:
+ {
+ unsigned int atype, v1, v2, v3;
+ unsigned int scope = TIPC_CLUSTER_SCOPE;
+ struct sockaddr_tipc *addr;
+
+ if (!PyTuple_Check(args)) {
+ PyErr_Format(
+PyExc_TypeError,
+"getsockaddrarg: "
+"AF_TIPC address must be tuple, not %.500s",
+Py_Type(args)->tp_name);
+ return 0;
+ }
+
+ if (!PyArg_ParseTuple(args,
+ "|I;Invalid TIPC address format",
+ &atype, &v1, &v2, &v3, &scope))
+ return 0;
+
+ addr = (struct sockaddr_tipc *) addr_ret;
+ memset(addr, 0, sizeof(struct sockaddr_tipc));
+
+ addr->family = AF_TIPC;
+ addr->scope = scope;
+ addr->addrtype = atype;
+
+ if (atype == TIPC_ADDR_NAMESEQ) {
+ addr->addr.nameseq.type = v1;
+ addr->addr.nameseq.lower = v2;
+ addr->addr.nameseq.upper = v3;
+ } else if (atype == TIPC_ADDR_NAME) {
+
[issue1646] Make socket support TIPC.
Alberto Bertogli added the comment:
On Tue, Dec 18, 2007 at 07:10:39PM -, Guido van Rossum wrote:
> Guido van Rossum added the comment:
>
> I'm okay with adding this, it doesn't add much code and is properly
> safeguarded by #ifdefs and has a configure.in patch.
Thanks!
Is there anything else I need to do in order to get this ready for
inclusion?
Thanks again,
Alberto
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1646>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1646] Make socket support TIPC.
Alberto Bertogli added the comment:
On Sat, Jan 05, 2008 at 10:08:15PM -, Christian Heimes wrote:
> I'm still waiting for a new patch. Your feature patch has been accepted
> but I won't commit it without doc updates.
I know, but holidays were not the best time to write documentation.
I'll probably send you the updated patch sometime this week; thanks for
the ping =)
Thanks,
Alberto
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1646>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1646] Make socket support TIPC.
Alberto Bertogli added the comment:
On Sun, Jan 06, 2008 at 02:45:35PM -, Alberto Bertogli wrote:
> I'll probably send you the updated patch sometime this week; thanks for
> the ping =)
Here are the three patches, rebased to the SVN commit 59815.
The first one is the same I've already submitted, the second adds the
documentation and the third two testcases.
The testcases are simple, but I think cover a reasonable amount of TIPC
specific code. If you want more, let me know.
The documentation is simple, as you told me, just a paragraph explaining
about the address format and another explaining the constants. Again, if
you want me to change anything, just let me know.
Finally, if you want me to rebase this on top of any other branch, you
guessed it, just let me know ;)
Thanks a lot,
Alberto
Added file: http://bugs.python.org/file9092/0001-Make-socket-support-TIPC.patch
Added file:
http://bugs.python.org/file9093/0002-Add-documentation-and-Misc-NEWS-entry-for-TIPC-suppo.patch
Added file:
http://bugs.python.org/file9094/0003-Add-unit-tests-for-TIPC-socket-support.patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1646>
__>From b643e5cad1f4fe32ed03847bd2e55bbae76b5e8b Mon Sep 17 00:00:00 2001
From: Alberto Bertogli <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 18:39:18 -0300
Subject: [PATCH] Make socket support TIPC.
TIPC (http://tipc.sf.net) is an open protocol designed for use in
clustered computer environments. It currently has an open source
implementation for Linux (>= 2.6.16), and VxWorks.
This patch adds optional Linux-only support for TIPC in the socket module.
---
Modules/socketmodule.c | 154 +++-
Modules/socketmodule.h |4 +
configure.in |2 +-
3 files changed, 158 insertions(+), 2 deletions(-)
diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c
index c30f1b3..e3f81db 100644
--- a/Modules/socketmodule.c
+++ b/Modules/socketmodule.c
@@ -7,7 +7,8 @@ This module provides an interface to Berkeley socket IPC.
Limitations:
- Only AF_INET, AF_INET6 and AF_UNIX address families are supported in a
- portable manner, though AF_PACKET and AF_NETLINK are supported under Linux.
+ portable manner, though AF_PACKET, AF_NETLINK and AF_TIPC are supported
+ under Linux.
- No read/write operations (use sendall/recv or makefile instead).
- Additional restrictions apply on some non-Unix platforms (compensated
for by socket.py).
@@ -52,6 +53,25 @@ Module interface:
the Ethernet protocol number to be received. For example:
("eth0",0x1234). Optional 3rd,4th,5th elements in the tuple
specify packet-type and ha-type/addr.
+- an AF_TIPC socket address is expressed as
+ (addr_type, v1, v2, v3 [, scope]); where addr_type can be one of:
+ TIPC_ADDR_NAMESEQ, TIPC_ADDR_NAME, and TIPC_ADDR_ID;
+ and scope can be one of:
+ TIPC_ZONE_SCOPE, TIPC_CLUSTER_SCOPE, and TIPC_NODE_SCOPE.
+ The meaning of v1, v2 and v3 depends on the value of addr_type:
+ if addr_type is TIPC_ADDR_NAME:
+ v1 is the server type
+ v2 is the port identifier
+ v3 is ignored
+ if addr_type is TIPC_ADDR_NAMESEQ:
+ v1 is the server type
+ v2 is the lower port number
+ v3 is the upper port number
+ if addr_type is TIPC_ADDR_ID:
+ v1 is the node
+ v2 is the ref
+ v3 is ignored
+
Local naming conventions:
@@ -1094,6 +1114,39 @@ makesockaddr(int sockfd, struct sockaddr *addr, int
addrlen, int proto)
}
#endif
+#ifdef HAVE_LINUX_TIPC_H
+ case AF_TIPC:
+ {
+ struct sockaddr_tipc *a = (struct sockaddr_tipc *) addr;
+ if (a->addrtype == TIPC_ADDR_NAMESEQ) {
+ return Py_BuildValue("I",
+ a->addrtype,
+ a->addr.nameseq.type,
+ a->addr.nameseq.lower,
+ a->addr.nameseq.upper,
+ a->scope);
+ } else if (a->addrtype == TIPC_ADDR_NAME) {
+ return Py_BuildValue("I",
+ a->addrtype,
+ a->addr.name.name.type,
+ a->addr.name.name.instance,
+ a->addr.name.name.instance,
+ a->scope);
+ } else if (a->addrtype == TIPC_ADDR_ID) {
+ return Py_BuildValue("I",
+ a->addrtype,
+ a->addr.id.node,
+
[issue1646] Make socket support TIPC.
Alberto Bertogli added the comment: On Mon, Jan 07, 2008 at 03:37:54PM -, Christian Heimes wrote: > The unit tests don't work for me (Ubuntu 7.10, Linux 2.6.22, i386) > > >>> srv = socket.socket(socket.AF_TIPC, socket.SOCK_RDM) > Traceback (most recent call last): > File "", line 1, in > File "/home/heimes/dev/python/trunk/Lib/socket.py", line 177, in __init__ > _sock = _realsocket(family, type, proto) > socket.error: [Errno 97] Address family not supported by protocol > > Do I have to set up my network device for TIPC? No, by default you have a single-node cluster fully capable of TIPC networking. But you do need the TIPC module loaded; have you tried modprobe tipc? If that works, the test cases should pass. I understand that this might be a problem because there is no time to check at runtime if you have TIPC enabled in your kernel (besides the obvious way of trying to create the socket and see if it fails); but you have the same problem with any network protocol (although obviously is much more common to have TIPC disabled than the rest of the supported ones). Do you want me to check for this in the conditional for inclusion? Thanks, Alberto __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1646> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45421] Remove dead code from html.parser
New submission from Alberto Mardegan : There appears to be some dead code in the html.parser module: https://github.com/python/cpython/blob/main/Lib/html/parser.py#L331-L337 Support for parser errors (with line and offset information) was removed long ago, so this code is useless now. The updatepos() and getpos() methods should also be removed. -- components: Library (Lib) messages: 403571 nosy: mardy priority: normal severity: normal status: open title: Remove dead code from html.parser type: enhancement ___ Python tracker <https://bugs.python.org/issue45421> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8739] Update to smtpd.py to RFC 5321
Alberto Trevino added the comment: David, I'd be happy to help, but I'm pretty busy for the next month. I read the description of your patch, and it sounds good to me. Anything that moves the project forward is always welcomed. Thanks for your work on this. -- ___ Python tracker <http://bugs.python.org/issue8739> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28718] '*' matches entire path in fnmatch
Alberto Galera added the comment: I see that they have commented on the lib that I made a few years ago (python-wildcard). The reason for the creation of that little fork started in this issue: https://bugs.python.org/issue25734 -- nosy: +Alberto Galera ___ Python tracker <https://bugs.python.org/issue28718> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34951] cookielib/cookiejar cookies' Expires date parse fails with long month names
New submission from Alberto Moral :
http.cookiejar (cookielib, for python2.*) does not parse some cookies' Expires
date.
For example: "Friday, 1-August-1997 00:00:00 GMT" does not work (while: "Fri,
01 Aug 1997 00:00:00 GMT" works fine)
This is basically due to long names of months (it is compared with
MONTHS_LOWER: list of 3-letter months). So, I propose a small change in the
definition of LOOSE_HTTP_DATE_RE (see fifth line):
LOOSE_HTTP_DATE_RE = re.compile(
r"""^
(\d\d?)# day
(?:\s+|[-\/])
(\w{3})\w* # month (3 first letters only)
...
Instead of:
LOOSE_HTTP_DATE_RE = re.compile(
r"""^
(\d\d?)# day
(?:\s+|[-\/])
(\w+) # month
...
I've tested only http.cookiejar (python 3.6), but I suposse the same change
will work on cookielib
Thanks in advance
--
components: Library (Lib)
messages: 327461
nosy: alb_moral
priority: normal
severity: normal
status: open
title: cookielib/cookiejar cookies' Expires date parse fails with long month
names
type: behavior
versions: Python 2.7, Python 3.6
___
Python tracker
<https://bugs.python.org/issue34951>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34951] cookielib/cookiejar cookies' Expires date parse fails with long month names
Alberto Moral added the comment: Thanks for your answer. I have not found any RFCs with full month names either. I'm afraid I'm not an expert here. But the case is that I get them in my work. Here is an example of response header: HTTP/1.1 200 OK Server: Oracle-iPlanet-Web-Server/7.0 Date: Tue, 10 Oct 2018 14:29:44 GMT Version-auth-credencial: v.3.0.1 Iplanet - Sun Solaris - Contexto Multiple Set-cookie: JSESSIONIDE=Del; expires=Friday, 1-August-1997 00:00:00 GMT; domain=... I do not know if it's an old date format (?)... or if it is a quite rare case... I have created some previous bash scripts using wget and they work fine, but I have had problems with python3 (and requests module) till I realized this issue. And it was not very easy: I am very new with python :( That's the reason of my proposal. It's just to be coherent: if we compare 3 letters of a month with MONTHS_LOWER, let's use just 3 (first) letters. Perhaps modifying LOOSE_HTTP_DATE_RE is not a good idea. Another option could be to truncate the month variable (mon). It could be done inside the _str2time funtion, for example: def _str2time(day, mon, yr, hr, min, sec, tz): mon = mon[:3] # assure 3 letters yr = int(yr) Anyway, I'll try to find why those long month names appear. Thank you -- ___ Python tracker <https://bugs.python.org/issue34951> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34951] cookielib/cookiejar cookies' Expires date parse fails with long month names
Alberto Moral added the comment: Yes, I was thinking that it could be a matter of configuration of the server (?). By the way, and just for fun, I've just realized that truncating mon at the begining of the _str2time funtion is a very bad idea because mon could also be an int. A better place is when looking the MONTHS_LOWER array index (and possible exception is handle): try: mon = MONTHS_LOWER.index(mon[:3].lower())+1 (perhaps in 2 sentences for clarity) OK, waiting for experts' comments. I'm really enjoying Python. -- ___ Python tracker <https://bugs.python.org/issue34951> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15637] Segfault reading null VMA (works fine in python 2.x)
New submission from Alberto Milone: The attached test case works fine in Python 2.7 but causes Pyhton 3.2 to segfault. -- components: ctypes files: randr_test messages: 168087 nosy: albertomilone priority: normal severity: normal status: open title: Segfault reading null VMA (works fine in python 2.x) type: crash versions: Python 3.2 Added file: http://bugs.python.org/file26782/randr_test ___ Python tracker <http://bugs.python.org/issue15637> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15637] Segfault reading null VMA (works fine in python 2.x)
Alberto Milone added the comment: it should just be possible to retrieve major and minor which we pass by reference to XRRQueryVersion. Without this pretty much any other call fails. Also, it works without problems with python 2.7. -- versions: -Python 3.3 ___ Python tracker <http://bugs.python.org/issue15637> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15637] Segfault reading null VMA (works fine in python 2.x)
Alberto Milone added the comment: I can confirm that the suggested changes solve the problem here. Thanks everyone! -- resolution: -> invalid ___ Python tracker <http://bugs.python.org/issue15637> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8739] Update to smtpd.py to RFC 5321
New submission from Alberto Trevino : This patch updates smtpd.py to be more RFC 5321 compliant. It contains: - EHLO support - Implement DATA size limit (32 MiB by default) - 8-bit mime extension plumbing (doesn't do anything, but accepts and records command) - Basic VRFY support - Basic HELP support - A few improvements to messages (more in line with RFC 5321 examples) - Misc. documentation updates The patch is specific to Python 3.1. I have not tried to backport the changes to 2.x. If possible, I would like the patch to be considered for inclusion to 3.2. -- components: Library (Lib) files: smtpd.py-0.2-rfc5321-enhancements.diff keywords: patch messages: 105902 nosy: alfmel, barry priority: normal severity: normal status: open title: Update to smtpd.py to RFC 5321 type: feature request versions: Python 3.1, Python 3.2 Added file: http://bugs.python.org/file17380/smtpd.py-0.2-rfc5321-enhancements.diff ___ Python tracker <http://bugs.python.org/issue8739> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8739] Update to smtpd.py to RFC 5321
Alberto Trevino added the comment: > Giampaolo Rodola' added the comment: > > Some comments: > > Is RFC 5321 completely implemented? Otherwise I would turn this in "as > defined in RFC 821 and part of RFC 5321". RFC 5321 obsoletes RFCs 821, 974, 1869 and 2821. I don't think we should make reference to them anymore. Perhaps say something like "implements RFC 5321 which supersedes RFC 821." As to how complete the implementation is, section 4.5.1 of RFC 5321 specifies the following as the minimum set of commands that should be supported in a conforming specification: EHLO, HELO, MAIL, RCPT, DATA, RSET, NOOP, QUIT, VRFY. The only gray area is VRFY which is supposed to see if a mailbox exists for a particular user. Since that function cannot be easily performed in this proxy smtpd server, section 3.5.3 states a 252 reply code should be returned. My patch returns code 252 if self.__getaddr returns true, or 502 if it returns false. > > - Implement DATA size limit (32 MiB by default) > I couldn't find any reference to this in RFC 5321. Is it recommended > somewhere else maybe? Also, issue 2518 and issue 1745035 are somewhat > related with this specific problem. It is not, but just seemed like good practice to advertise the limit in EHLO and enforce it. My patch doesn't do a good job of enforcing it since it enforces it before doing process_message. The problems with 2518 and 1745035 are still there. > Since you implemented HELP command in the first place it would be good to > do it completely. RFC 5321 doesn't specify it must accept arguments, but I agree it is a good idea. I'll work on that and submit a new patch. > Too bad smtpd currently lacks a test suite. > Before going any further with this issue I would recommend to write tests > first. I have a patch for adding a basic test suite for smtpd module I > hope I'll be able to submit within this week. It would be great if you could implement a test suite. -- ___ Python tracker <http://bugs.python.org/issue8739> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8739] Update to smtpd.py to RFC 5321
Alberto Trevino added the comment: I have attached a version 2 of the patch. This patch includes everything in the first version, and adds the following: - Support for help arguments (HELP MAIL, for example) - Support for setting the maximum message size from the command line This last feature adds the -s or --size option to the command line. It allows the user to specify the maximum size for the message. It is set to 0 for the default, meaning no limit. This mimics the original behavior of module. If you specify a size (like --size 32768), it will reject messages larger than the specified number of bytes (32KiB in this case). If you don't specify the size, the response of EHLP won't list SIZE as one of the extensions. But, if a size is specified, then it will show it on EHLP. Hopefully these two changes will address some of the concerns that have been brought up. -- Added file: http://bugs.python.org/file17415/smtpd.py-0.2-rfc5321-enhancements-2.diff ___ Python tracker <http://bugs.python.org/issue8739> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8739] Update to smtpd.py to RFC 5321
Alberto Trevino added the comment: On Thursday 20 May 2010 07:46:43 am you wrote: > If you don't specify the size, the response of EHLP won't list > SIZE as one of the extensions. But, if a size is specified, then it > will show it on EHLP. Sorry, the EHLP above should be EHLO. Fat fingers, little sleep, talk about help... you get the idea. -- ___ Python tracker <http://bugs.python.org/issue8739> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9168] setuid in smtp.py sheds privileges before binding port
New submission from Alberto Trevino : The SMTP proxy server in Python (smtpd.py) allows you to shed privileges and run as user nobody. However, if you are trying to use port 25, the server will shed privileges before binding the port, causing a bind failure. By moving the setuid code between the creation of the proxy server and the aysncore loop, we can bind a port below 1024 and run as nobody. -- components: Library (Lib) files: smtpd.py-0.2-setuid-fix.diff keywords: patch messages: 109336 nosy: alfmel, barry priority: normal severity: normal status: open title: setuid in smtp.py sheds privileges before binding port versions: Python 3.2 Added file: http://bugs.python.org/file17871/smtpd.py-0.2-setuid-fix.diff ___ Python tracker <http://bugs.python.org/issue9168> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8739] Update to smtpd.py to RFC 5321
Alberto Trevino added the comment: What is the status of this patch? Is there anything else I need to do? Any remaining concerns that would stop this patch from being merged? -- ___ Python tracker <http://bugs.python.org/issue8739> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8739] Update to smtpd.py to RFC 5321
Alberto Trevino added the comment:
On Monday, July 05, 2010 10:41:28 am you wrote:
> Yes, the fact that there are no unit tests for the new functionality.
Sorry to take so long to reply. I have attached the latest version of the
patch which does everything in rev. 2 of the patch, patches the setuid
problem discussed in issue 9168, updates to the unit test to account for the
changes and to test the new functionality, plus some little changes here and
there.
Please review and advise.
--
Added file:
http://bugs.python.org/file18332/smtpd.py-0.2-rfc5321-enhancements-4.diff
___
Python tracker
<http://bugs.python.org/issue8739>
___diff -aur Python-3.1.2.orig/Lib/smtpd.py Python-3.1.2/Lib/smtpd.py
--- Python-3.1.2.orig/Lib/smtpd.py 2009-02-21 13:59:32.0 -0700
+++ Python-3.1.2/Lib/smtpd.py 2010-08-02 08:23:04.424066197 -0600
@@ -1,5 +1,5 @@
#! /usr/bin/env python
-"""An RFC 2821 smtp proxy.
+"""An RFC 5321 smtp proxy.
Usage: %(program)s [options] [localhost:localport [remotehost:remoteport]]
@@ -20,6 +20,11 @@
Use `classname' as the concrete SMTP proxy class. Uses `PureProxy' by
default.
+--size limit
+-s limit
+Restrict the total size of the incoming message to "limit" number of
+bytes. Defaults to 0 (no limit).
+
--debug
-d
Turn on debugging prints.
@@ -35,10 +40,9 @@
and if remoteport is not given, then 25 is used.
"""
-
# Overview:
#
-# This file implements the minimal SMTP protocol as defined in RFC 821. It
+# This file implements the minimal SMTP protocol as defined in RFC 5321. It
# has a hierarchy of classes which implement the backend functionality for the
# smtpd. A number of classes are provided:
#
@@ -59,15 +63,18 @@
# gets forwarded to a real backend smtpd, as with PureProxy. Again, errors
# are not handled correctly yet.
#
-# Please note that this script requires Python 2.0
+# Please note that this script requires Python 3.0
#
# Author: Barry Warsaw
#
+# Contributors:
+# Alberto Trevino
+#
# TODO:
#
# - support mailbox delivery
# - alias files
-# - ESMTP
+# - Handle more ESMTP extensions
# - handle error codes from the backend smtpd
import sys
@@ -82,7 +89,7 @@
__all__ = ["SMTPServer","DebuggingServer","PureProxy","MailmanProxy"]
program = sys.argv[0]
-__version__ = 'Python SMTP proxy version 0.2'
+__version__ = 'Python SMTP proxy version 0.21'
class Devnull:
@@ -96,7 +103,6 @@
COMMASPACE = ', '
-
def usage(code, msg=''):
print(__doc__ % globals(), file=sys.stderr)
if msg:
@@ -104,16 +110,16 @@
sys.exit(code)
-
class SMTPChannel(asynchat.async_chat):
COMMAND = 0
DATA = 1
-def __init__(self, server, conn, addr):
+def __init__(self, server, conn, addr, size):
asynchat.async_chat.__init__(self, conn)
self.__server = server
self.__conn = conn
self.__addr = addr
+self.__size = size
self.__line = []
self.__state = self.COMMAND
self.__greeting = 0
@@ -122,6 +128,7 @@
self.__data = ''
self.__fqdn = socket.getfqdn()
self.__peer = conn.getpeername()
+self.__8bitmime = False
print('Peer:', repr(self.__peer), file=DEBUGSTREAM)
self.push('220 %s %s' % (self.__fqdn, __version__))
self.set_terminator(b'\r\n')
@@ -153,7 +160,7 @@
arg = line[i+1:].strip()
method = getattr(self, 'smtp_' + command, None)
if not method:
-self.push('502 Error: command "%s" not implemented' % command)
+self.push('500 Error: command "%s" not recognized' % command)
return
method(arg)
return
@@ -162,7 +169,7 @@
self.push('451 Internal confusion')
return
# Remove extraneous carriage returns and de-transparency according
-# to RFC 821, Section 4.5.2.
+# to RFC 5321, Section 4.5.2.
data = []
for text in line.split('\r\n'):
if text and text[0] == '.':
@@ -170,18 +177,39 @@
else:
data.append(text)
self.__data = NEWLINE.join(data)
-status = self.__server.process_message(self.__peer,
- self.__mailfrom,
- self.__rcpttos,
- self.__data)
-self.__rcpttos = []
-self.__mailfrom = None
-self.__state = self.COMMAN
[issue8739] Update to smtpd.py to RFC 5321
Alberto Trevino added the comment: Sorry. This is my first submission to Python, so I'm learning the process as I go. This latest patch is done against today's SVN snapshot. Just to summarize, it does the following: * Updates the main smtpd.py module to make it RFC 5321 compliant: - Adds EHLO support - Provides basic VRFY support - Updated messages (more in line with RFC 5321 examples) * Adds additional functionality to smtpd.py: - Adds HELP support - Implements DATA size limits (optional feature -- backward compatible) - 8BITMIME extension plubming * Fixes setuid bug in smtpd.py as explained in issue 9168 * Updates test-smtpd.py to test new functionality * Updates test-smtpdlib.py to work with updates to smtpd.py Again, please review and comment as necessary. -- Added file: http://bugs.python.org/file18397/smtpd.py-0.2-rfc5321-enhancements-5.diff ___ Python tracker <http://bugs.python.org/issue8739> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9168] setuid in smtp.py sheds privileges before binding port
Changes by Alberto Trevino : -- type: -> crash versions: +Python 3.1 -Python 3.2 ___ Python tracker <http://bugs.python.org/issue9168> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29271] Task.current_task(None) returns unexpected result
Changes by Alberto Berti : -- nosy: +azazel ___ Python tracker <http://bugs.python.org/issue29271> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25734] fnmatch regular expression can be improved
New submission from Alberto Galera:
# https://hg.python.org/cpython/file/tip/Lib/fnmatch.py
fnmatch reviewing the code I've noticed that the outcome of the regular
expression all returns generated in the first result
l97:
res = res + '.*'
to:
res = res + '.*?'
l100:
return res + '\Z(?ms)'
to:
return res + '$(?ms)'
example test:
import re
import fnmatch
urls = ['example/l1/l2/test3-1.py',
'example/l1/test2-1.py',
'example/l1/test2-2.py',
'example/l1/l2/l3/test4-1.py']
regex = fnmatch.translate('example/*')
# 'example\\/.*\\Z(?ms)'
re.findall(regex, "\n".join(urls))
# return
['example/l1/l2/test3-1.py\nexample/l1/test2-1.py\nexample/l1/test2-2.py\nexample/l1/l2/l3/test4-1.py']
# suggested change
re.findall('example\\/.*?$(?ms)', "\n".join(urls))
# return ['example/l1/l2/test3-1.py',
# 'example/l1/test2-1.py',
# 'example/l1/test2-2.py',
# 'example/l1/l2/l3/test4-1.py']
--
components: Library (Lib)
messages: 255361
nosy: Alberto Galera
priority: normal
severity: normal
status: open
title: fnmatch regular expression can be improved
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue25734>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40982] copytree example in shutil
New submission from Alberto Torres Barrán : The copytree example in https://docs.python.org/3/library/shutil.html#copytree-example does not match the source code, even removing docstrings. In particular is missing parameters and the exceptions are in the wrong order (Error will never be reachable since it is n instance of OSError). -- assignee: docs@python components: Documentation messages: 371535 nosy: Alberto Torres Barrán, docs@python priority: normal severity: normal status: open title: copytree example in shutil versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue40982> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31154] Path.replace and Path.rename naming, behavior and documentation
New submission from Alberto Gomez-Casado: I find the naming of Path.replace quite unfortunate, coming from the os.path and basestring mindset, the expectation would be that it would change some substring by another substring in the Path instance. Instead, it _moves_ the file indicated by the Path object in the file system. Most of the methods of Path have no effect in the filesystem, and we have here one with a slightly misleading name which goes and moves your files around. Practically the same operation is done with Path.rename, which is less surprising since it matches popular OS commands/UIs (ren, Rename). IMHO Path.replace should not exist as is and a keyword modifier (silent?) for Path.rename toggles between the minor behavior differences of the two. Additionally: Both calls lack any kind of return, which leads me to expect after a rename/replace the Path instance would be changed to the new path. This is not the case, after the call the Path instance keeps "pointing" to the previous (and quite likely now useless) path. Returning the new path would be another reasonable option. In any case, I think the documentation should mention this behavior explicitly. And, while we are at it, having implemented the relatively dangerous replace/rename (along with convenience shorcuts for reading, writing, opening...), why was a Path.copy not included? -- assignee: docs@python components: Documentation, Library (Lib) messages: 299976 nosy: Alberto Gomez-Casado, docs@python priority: normal severity: normal status: open title: Path.replace and Path.rename naming, behavior and documentation type: behavior versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue31154> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31163] Return destination path in Path.rename and Path.replace
New submission from Alberto Gomez-Casado: Extracted from issue31154 Both calls lack any kind of return, which leads me to expect after a rename/replace the Path instance would be changed to the new path. This is not the case (reading the PEP I have seen Path instances are kind of immutable), after the call the Path instance keeps "pointing" to the previous (and quite likely now useless) path. Returning the new path would be a reasonable option. In any case, I think the documentation should mention this behavior explicitly. -- assignee: docs@python components: Documentation, Library (Lib) messages: 300019 nosy: Alberto Gomez-Casado, docs@python, pitrou priority: normal severity: normal status: open title: Return destination path in Path.rename and Path.replace type: enhancement versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue31163> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8738] cPickle dumps(tuple) != dumps(loads(dumps(tuple)))
New submission from Alberto Planas Domínguez :
Sometimes, when I use cPickle to serialize tuples of strings, I get different
dumps() result for the same tuple:
import cPickle
t = ('', 'JOHN')
s1 = cPickle.dumps(t)
s2 = cPickle.dumps(cPickle.loads(cPickle.dumps(t)))
assert s1 == s2 # AssertionError
With cPickle doesn't matter what protocol use por dumps(). The assertion is Ok
if I use the pickle module instead of cPickle.
This means that I can't use a serialized object as a key in a map/dict object.
--
messages: 105896
nosy: Alberto.Planas.Domínguez
priority: normal
severity: normal
status: open
title: cPickle dumps(tuple) != dumps(loads(dumps(tuple)))
type: behavior
versions: Python 2.6
___
Python tracker
<http://bugs.python.org/issue8738>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22888] ensurepip and distutils' build_scripts fails on Windows when path to Python contains accented characters
New submission from José Alberto Goncalves:
Summary:
Python 3.4's venv works fine in Windows, and pip works fine when installing
both pure Python libraries and extension modules. However, when the virtual
environment is under a path with non-ASCII characters, attempting to install a
package that specifies console_scripts or scripts (like pip or mutagen,
respectivelly), it fails with encoding errors.
I looked around the Internet for a solution but the best I could find was Issue
#10419, which is over 3 years old and is marked as resolved, and couldn't find
any other open issue about this.
Details of my case:
I created a Python 3.4 (32-bit) virtualenv via Python Tools for Visual Studio,
on windows 8.1 (64-bit), in a folder that is under my home directory
(C:\Users\José Alberto\), which happens to contain an accented character, using
the latest Python you can download from the homepage.
Via Powershell I activated the virtualenv and tried to execute pip install
mutagen (https://pypi.python.org/pypi/mutagen, it is relevant because it
specifies scripts in its setup.py). The installation failed with the following
error:
Downloading/unpacking mutagen
Running setup.py (path:C:\Users\José
Alberto\Documents\podtimizer\env_podtimizer\build\mutagen\setup.py) egg_info for
package mutagen
Installing collected packages: mutagen
Running setup.py install for mutagen
Traceback (most recent call last):
File "C:\Python34\lib\distutils\command\build_scripts.py", line 114, in
copy_scripts
shebang.decode('utf-8')
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe9 in position 14:
invalid continuation byte
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "", line 1, in
File "C:\Users\JosÚ
Alberto\Documents\podtimizer\env_podtimizer\build\mutagen\setup.py", line 277,
in
"""
File "C:\Python34\lib\distutils\core.py", line 148, in setup
dist.run_commands()
File "C:\Python34\lib\distutils\dist.py", line 955, in run_commands
self.run_command(cmd)
File "C:\Python34\lib\distutils\dist.py", line 974, in run_command
cmd_obj.run()
File "C:\Users\JosÚ
Alberto\Documents\podtimizer\env_podtimizer\lib\site-packages\setuptools-6.0.2-py3.4.egg\setuptools\command\install.py",
line 61, in run
File "C:\Python34\lib\distutils\command\install.py", line 539, in run
self.run_command('build')
File "C:\Python34\lib\distutils\cmd.py", line 313, in run_command
self.distribution.run_command(command)
File "C:\Python34\lib\distutils\dist.py", line 974, in run_command
cmd_obj.run()
File "C:\Python34\lib\distutils\command\build.py", line 126, in run
self.run_command(cmd_name)
File "C:\Python34\lib\distutils\cmd.py", line 313, in run_command
self.distribution.run_command(command)
File "C:\Python34\lib\distutils\dist.py", line 974, in run_command
cmd_obj.run()
File "C:\Python34\lib\distutils\command\build_scripts.py", line 50, in run
self.copy_scripts()
File "C:\Python34\lib\distutils\command\build_scripts.py", line 118, in
copy_scripts
"from utf-8".format(shebang))
ValueError: The shebang (b'#!C:\\Users\\Jos\xe9
Alberto\\Documents\\podtimizer\\env_podtimizer\\Scripts\\python.exe\n') is not
decodable from utf-8
I looked around the Internet for a solution, but the best I could find was the
Issue #10419, which is over 3 years old and is marked as closed and resolved.
The last comment mentions a fix that was commited to Distribute around that
time, with the caveat that entry points script creation would fail if the path
contained unencodeable characters (which sounds exactly like the problem I'm
having). I Couldn't find an open issue to follow up on this.
I went to the source of the error, around
Lib/distutils/command/build_scripts.py:106. Since this is Windows, the result
of os.fsencode() uses the encoding 'mbcs' (as reported by Python), then it
tries to decode it back using utf-8, and it blows up:
>>> import os
>>> os.fsencode('C:\\Users\\José Alberto\\')
b'C:\\Users\\Jos\xe9 Alberto\\'
>>> 'C:\\Users\\José Alberto\\'.encode('utf-8')
b'C:\\Users\\Jos\xc3\xa9 Alberto\\'
I commented both try..except after the os.fsencode and it worked, but
commenting random code whose purpose I don't fully understand doesn't seem like
a good strategy.
While testing for the above, I found I couldn't finish installing pip
successfully on a virtualenv using just the Python installed from python.org.
On Powershell I creat
[issue22887] ensurepip and distutils' build_scripts fails on Windows when path to Python contains accented characters
New submission from José Alberto Goncalves:
Summary:
Python 3.4's venv works fine in Windows, and pip works fine when installing
both pure Python libraries and extension modules. However, when the virtual
environment is under a path with non-ASCII characters, attempting to install a
package that specifies console_scripts or scripts (like pip or mutagen,
respectivelly), it fails with encoding errors.
I looked around the Internet for a solution but the best I could find was Issue
#10419, which is over 3 years old and is marked as resolved, and couldn't find
any other open issue about this.
Details of my case:
I created a Python 3.4 (32-bit) virtualenv via Python Tools for Visual Studio,
on windows 8.1 (64-bit), in a folder that is under my home directory
(C:\Users\José Alberto\), which happens to contain an accented character, using
the latest Python you can download from the homepage.
Via Powershell I activated the virtualenv and tried to execute pip install
mutagen (https://pypi.python.org/pypi/mutagen, it is relevant because it
specifies scripts in its setup.py). The installation failed with the following
error:
Downloading/unpacking mutagen
Running setup.py (path:C:\Users\José
Alberto\Documents\podtimizer\env_podtimizer\build\mutagen\setup.py) egg_info for
package mutagen
Installing collected packages: mutagen
Running setup.py install for mutagen
Traceback (most recent call last):
File "C:\Python34\lib\distutils\command\build_scripts.py", line 114, in
copy_scripts
shebang.decode('utf-8')
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe9 in position 14:
invalid continuation byte
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "", line 1, in
File "C:\Users\JosÚ
Alberto\Documents\podtimizer\env_podtimizer\build\mutagen\setup.py", line 277,
in
"""
File "C:\Python34\lib\distutils\core.py", line 148, in setup
dist.run_commands()
File "C:\Python34\lib\distutils\dist.py", line 955, in run_commands
self.run_command(cmd)
File "C:\Python34\lib\distutils\dist.py", line 974, in run_command
cmd_obj.run()
File "C:\Users\JosÚ
Alberto\Documents\podtimizer\env_podtimizer\lib\site-packages\setuptools-6.0.2-py3.4.egg\setuptools\command\install.py",
line 61, in run
File "C:\Python34\lib\distutils\command\install.py", line 539, in run
self.run_command('build')
File "C:\Python34\lib\distutils\cmd.py", line 313, in run_command
self.distribution.run_command(command)
File "C:\Python34\lib\distutils\dist.py", line 974, in run_command
cmd_obj.run()
File "C:\Python34\lib\distutils\command\build.py", line 126, in run
self.run_command(cmd_name)
File "C:\Python34\lib\distutils\cmd.py", line 313, in run_command
self.distribution.run_command(command)
File "C:\Python34\lib\distutils\dist.py", line 974, in run_command
cmd_obj.run()
File "C:\Python34\lib\distutils\command\build_scripts.py", line 50, in run
self.copy_scripts()
File "C:\Python34\lib\distutils\command\build_scripts.py", line 118, in
copy_scripts
"from utf-8".format(shebang))
ValueError: The shebang (b'#!C:\\Users\\Jos\xe9
Alberto\\Documents\\podtimizer\\env_podtimizer\\Scripts\\python.exe\n') is not
decodable from utf-8
I looked around the Internet for a solution, but the best I could find was the
Issue #10419, which is over 3 years old and is marked as closed and resolved.
The last comment mentions a fix that was commited to Distribute around that
time, with the caveat that entry points script creation would fail if the path
contained unencodeable characters (which sounds exactly like the problem I'm
having). I Couldn't find an open issue to follow up on this.
I went to the source of the error, around
Lib/distutils/command/build_scripts.py:106. Since this is Windows, the result
of os.fsencode() uses the encoding 'mbcs' (as reported by Python), then it
tries to decode it back using utf-8, and it blows up:
>>> import os
>>> os.fsencode('C:\\Users\\José Alberto\\')
b'C:\\Users\\Jos\xe9 Alberto\\'
>>> 'C:\\Users\\José Alberto\\'.encode('utf-8')
b'C:\\Users\\Jos\xc3\xa9 Alberto\\'
I commented both try..except after the os.fsencode and it worked, but
commenting random code whose purpose I don't fully understand doesn't seem like
a good strategy.
While testing for the above, I found I couldn't finish installing pip
successfully on a virtualenv using just the Python installed from python.org.
On Powershell I creat
[issue39293] Windows 10 64-bit needs reboot after install
Change by Alberto N Leilani Campos : Added file: https://bugs.python.org/file48854/windows-ssh-tools.snapshot.json ___ Python tracker <https://bugs.python.org/issue39293> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22417] PEP 476: verify HTTPS certificates by default
Carlos Alberto Lopez Perez added the comment: The python 2.7 documentation for urrlib still has a big warning notice at the top saying: """ Warning When opening HTTPS URLs, it does not attempt to validate the server certificate. Use at your own risk! """ ^^ https://docs.python.org/2/library/urllib.html I believe this is incorrect since this patch was backported to the 2.7 branch. I checked it, and it verifies SSL certs by default. I guess the documentation for urllib should be updated to remove that warning? -- nosy: +clopez ___ Python tracker <http://bugs.python.org/issue22417> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
