[issue2987] RFC2732 support for urlparse (e.g. http://[::1]:80/)
Sérgio added the comment:
Hi, with python-2.6.2-2.fc12.i686
In: x ="http://www.somesite.com/images/rubricas/";
In: urlparse.urljoin(x, '07.11.2009-9:54:12-1.jpg')
Out: '07.11.2009-9:54:12-1.jpg' !?
In: urlparse.urljoin(x, './07.11.2009-9:54:12-1.jpg')
Out: 'http://www.somesite.com/images/rubricas/07.11.2009-9:54:12-1.jpg'
urlparse.urlparse('07.11.2009-9:54:12-1.jpg')
is wrong
but
urlparse.urlparse('./07.11.2009-9:54:12-1.jpg')
isn't.
think about that please
--
nosy: +sergiomb2
___
Python tracker
<http://bugs.python.org/issue2987>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3932] HTMLParser cannot handle '&' and non-ascii characters in attribute names
Sérgio added the comment: the patch fix parsing in simple tag a with title with ?! and accents like this: -- nosy: +sergiomb2 ___ Python tracker <http://bugs.python.org/issue3932> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9646] Mutable default function parameter warning
New submission from Sérgio Surkamp : The documentation states that the default value of function parameter, if mutable, can change it's default value at runtime due to be evaluated only once on function object creation. I would like to suggest the inclusion of an default language warning when this kind of construction is used, as it's Python specific behavior and can lead to "strange behavior" or misuse by programmers that are migrating from other languages to Python. Documentation reference: http://docs.python.org/reference/compound_stmts.html#function -- components: None messages: 114394 nosy: surkamp priority: normal severity: normal status: open title: Mutable default function parameter warning type: behavior versions: Python 2.5, Python 2.6, Python 2.7 ___ Python tracker <http://bugs.python.org/issue9646> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7779] smtplib SASL PLAIN authentication error
New submission from Sérgio Surkamp :
There is bug in PLAIN mechanism's of smtplib. The generated base64 string fail
when the password start with numbers. As long as I could find, the error occur
in method encode_plain. Using the null character (\0) in hexadecimal
representation (\x00) seems to fix the problem.
Origin of the problem:
def encode_plain(user, password):
return encode_base64("\0%s\0%s" % (user, password), eol="")
Proposed fix:
def encode_plain(user, password):
return encode_base64("\x00%s\x00%s" % (user, password), eol="")
Current result:
>>> from email.base64mime import encode as encode_base64
>>> import base64
>>> encode_base64("\0user\0123foo", eol="")
'AHVzZXIKM2Zvbw=='
>>> f = base64.decodestring('AHVzZXIKM2Zvbw==')
>>> f
'\x00user\n3foo'
Expected result:
>>> from email.base64mime import encode as encode_base64
>>> import base64
>>> encode_base64("\x00user\x00123foo", eol="")
'AHVzZXIAMTIzZm9v'
>>> f = base64.decodestring('AHVzZXIAMTIzZm9v')
>>> f
'\x00user\x00123foo'
--
components: Extension Modules
messages: 98295
nosy: surkamp
severity: normal
status: open
title: smtplib SASL PLAIN authentication error
versions: Python 2.5, Python 2.6
___
Python tracker
<http://bugs.python.org/issue7779>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7779] smtplib SASL PLAIN authentication error
Sérgio Surkamp added the comment: The SASL protocol says that the encoded base64 should be formed from: null + login + null + password The smtplib is not doing it, instead its "converting" the \012 (\0 + 2 first chars from password) in the char "\n", and it's right in the python way to see the things, it's not the bug reported here. The bug is a patch to change the null character representation from \0 to \x00 (using the hexadecimal representation) in the encode_base64 call to prevent the "conversion" and generate the right base64 encoded string. -- status: closed -> open ___ Python tracker <http://bugs.python.org/issue7779> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7779] smtplib SASL PLAIN authentication error
Sérgio Surkamp added the comment: Got your point. Sorry. -- ___ Python tracker <http://bugs.python.org/issue7779> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4177] Crash in MIMEText on FreeBSD
New submission from Sérgio Surkamp <[EMAIL PROTECTED]>: If you try to create a MIMEText object from a very large string (test case include a 40Mbytes string), the program just eat all the CPU and with high memory usage or raise a MemoryError. Sometimes it just deadlocks when using _charset = "iso-8859-1". Use the submited file and the script to test the case. ** On Linux its very slow, but work's ** - the problem occour on a FreeBSD installation. -- components: Library (Lib), Unicode files: test_MIMEText.tar.bz2 messages: 75097 nosy: surkamp severity: normal status: open title: Crash in MIMEText on FreeBSD type: behavior versions: Python 2.5, Python 2.5.3 Added file: http://bugs.python.org/file11859/test_MIMEText.tar.bz2 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4177> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4177] Crash in MIMEText on FreeBSD
Sérgio Surkamp <[EMAIL PROTECTED]> added the comment: Testing on Linux: $ ulimit -m 128000 $ ulimit -v 196000 $ python test_MIMEText.py [...] Traceback (most recent call last): File "test_MIMEText.py", line 23, in txt = MIMEText(buffer, _subtype="plain", _charset="iso-8859-1") File "/usr/lib/python2.5/email/mime/text.py", line 30, in __init__ self.set_payload(_text, _charset) File "/usr/lib/python2.5/email/message.py", line 220, in set_payload self.set_charset(charset) File "/usr/lib/python2.5/email/message.py", line 262, in set_charset self._payload = charset.body_encode(self._payload) File "/usr/lib/python2.5/email/charset.py", line 386, in body_encode return email.quoprimime.body_encode(s) File "/usr/lib/python2.5/email/quoprimime.py", line 198, in encode body = fix_eols(body) File "/usr/lib/python2.5/email/utils.py", line 77, in fix_eols s = re.sub(r'(? <http://bugs.python.org/issue4177> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4177] Crash in MIMEText on FreeBSD
Sérgio Surkamp <[EMAIL PROTECTED]> added the comment: > Your text file is ~40 MB. Python may allocate mutiple objects bigger than 40 MB to create the email content. The algorithm should be changed to work on a stream (process small chunks, eg. 4 KB) instead of manipule the full text in memory (+40,000 KB). The original text block is about 5 to 9 Mbytes - its a server generated report by pflogsum. When it came to our mailing list processing program (wrote by someone else in Python), it freezes building the MIMEText object. Actually no MemoryError isn't raised, just a sudden freeze of the running thread. Unfortunately the test script submited does not do the same behavior, maybe some other things are freezing the software instead of raise the MemoryError. I have checked for blocks of try: ... except ...: pass that could hide the problem, but found nothing. I have already limited the size on Postfix, but the strange thing is why this happens on FreeBSD and don't on Linux. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4177> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4177] Crash in MIMEText on FreeBSD
Sérgio Surkamp <[EMAIL PROTECTED]> added the comment: - FreeBSD version? FreeBSD 7.0-RELEASE - CPU, memory? CPU: 2 x Pentium III 1.133 GHz Memory: 512 Mbytes - Full Python version? Python 2.5.2 (r252:60911, Oct 2 2008, 10:03:50) [GCC 4.2.1 20070719 [FreeBSD]] on freebsd7 > On "freeze", the process uses 0% or 100% of the CPU time? You can use the strace program to trace Python activity during the freeze. Usually 100%. But saw it with more (using both CPU's), I think that mean more then one thread "freezed". I will download your trace program and do some tests with it. Ill try to collect some informations using GDB too. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4177> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4177] Crash in MIMEText on FreeBSD
Sérgio Surkamp <[EMAIL PROTECTED]> added the comment: When I first saw the problem, the email system queue was stopped about 2 days (weekend) :-( The email system control the number of open threads, so I wasn't opening new threads too and issuing many warnings about it on logs Anyway, already installed the ptrace tool and Ill start debuging when I came back from launch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4177> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4177] Crash in MIMEText on FreeBSD
Sérgio Surkamp <[EMAIL PROTECTED]> added the comment: Ok. Something is very wrong with our code too. I have dumped the text that's cousing the "freeze" and run it using the test case scripts. It worked slow, but worked. It seems that our application is eating too many memory from server (about 60Mbytes for a 2.4Mbytes message), so its obviously a application bug/leak. Unfortunately I cant submit the files for performance test, becose they may contain confidential information. As long as I can see on GDB, the python process is in a loop inside this functions: #0 0x2825798e in memcpy () from /lib/libc.so.7 #1 0x080a4607 in PyUnicodeUCS4_Concat () #2 0x080aec8d in PyEval_EvalFrameEx () #3 0x080b2c49 in PyEval_EvalCodeEx () #4 0x080b111a in PyEval_EvalFrameEx () #5 0x080b2c49 in PyEval_EvalCodeEx () #6 0x080b111a in PyEval_EvalFrameEx () #7 0x080b1f65 in PyEval_EvalFrameEx () #8 0x080b2c49 in PyEval_EvalCodeEx () #9 0x080b111a in PyEval_EvalFrameEx () #10 0x080b2c49 in PyEval_EvalCodeEx () #11 0x080eebd6 in PyClassMethod_New () #12 0x08059ef7 in PyObject_Call () #13 0x0805f341 in PyClass_IsSubclass () #14 0x08059ef7 in PyObject_Call () #15 0x080ac86c in PyEval_CallObjectWithKeywords () #16 0x080629d6 in PyInstance_New () #17 0x08059ef7 in PyObject_Call () #18 0x080af2bb in PyEval_EvalFrameEx () #19 0x080b2c49 in PyEval_EvalCodeEx () #20 0x080b111a in PyEval_EvalFrameEx () #21 0x080b1f65 in PyEval_EvalFrameEx () #22 0x080b1f65 in PyEval_EvalFrameEx () #23 0x080b1f65 in PyEval_EvalFrameEx () #24 0x080b2c49 in PyEval_EvalCodeEx () #25 0x080eec4e in PyClassMethod_New () #26 0x08059ef7 in PyObject_Call () #27 0x0805f341 in PyClass_IsSubclass () #28 0x08059ef7 in PyObject_Call () #29 0x080ac86c in PyEval_CallObjectWithKeywords () #30 0x080d4b58 in initthread () #31 0x28175acf in pthread_getprio () from /lib/libthr.so.3 #32 0x in ?? () Every memcpy call take a lot to complete, but it seems a problem with GDB debugging as it eats 80% to 95% of the CPU and python just 1% or 2%. How python charset conversion works from inside? It duplicates the original string every character substitution? If this is the case, shouldn't be better to count the substituitions, calculate the amount of needed memory and make just one allocation for the new string? Then copy the unmodified characters from the original to the new string and change other chars as needed? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4177> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7390] inconsistent type return
New submission from Sérgio Surkamp : The type function returns inconsistent value depending on class hierarchy. >>> class X: ... pass ... >>> x = X() >>> type(x) >>> class Y(object): ... pass ... >>> x = Y() >>> type(x) >>> >>> class Z(X): ... pass ... >>> x = Z() >>> type(x) >>> class K(Y): ... pass ... >>> x = K() >>> type(x) All should reply 'instance'. As long as I have read on documentation the only way to change the type function return is by writing a __metaclass__ (PEP3115). -- components: Interpreter Core messages: 95670 nosy: surkamp severity: normal status: open title: inconsistent type return type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue7390> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Sérgio Durigan Júnior <[EMAIL PROTECTED]> added the comment: Hi, I'd like to know the status of this issue. I'm having the same problems here with PPC64, and the patch that Bob Atkins has sent works fine for me too. Would you intend to apply this patch in upstream? Thanks in advance. -- nosy: +sergiodj _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1628484> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Sérgio Durigan Júnior <[EMAIL PROTECTED]> added the comment: Hi Martin, Thanks for your quick answer. I'd like to know what can we do to push this patch into upstream. Does the fact that the patch is posted in a bug report (and not in a developer's mailing list) is slowing down the reviewing process? Regards. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1628484> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Sérgio Durigan Júnior <[EMAIL PROTECTED]> added the comment: Hi Martin, Actually, I know that you can use CC to do it, but IMHO that's not the correct approach. I understand too you concern about adding @CFLAGS@, but I think the user should be able to define his/her own CFLAGS, and this is not implemented yet. Do you agree with that? Regards. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1628484> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue858809] Use directories from configure rather than hardcoded
Sérgio Durigan Júnior <[EMAIL PROTECTED]> added the comment: Hi, Continuing with my effort to improve Python's build system, I'd really like to know why this issue has not been solved yet. I mean, apparently this problem is still present in Python 2.5, since I can't change the library's path with --libdir configure's flag. Any news about it? -- nosy: +sergiodj Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue858809> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Sérgio Durigan Júnior <[EMAIL PROTECTED]> added the comment: Hi Martin, This is what you get when you try to build a 64-bit Python on a biarch machine (64-bit kernel, 32-bit userspace), using a gcc that generates natively 32-bit objects (therefore, you *must* pass the '-m64' option for the compiler): #> ./configure --enable-shared --target=powerpc64-unknown-linux BASECFLAGS='-m64' #> make gcc -pthread -c -m64 -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -fPIC -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c In file included from Include/Python.h:57, from ./Modules/python.c:3: Include/pyport.h:761:2: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." make: *** [Modules/python.o] Error 1 As you can see, the compilation fails. Now, if I try this configure line: #> ./configure --enable-shared --target=powerpc64-unknown-linux BASECFLAGS='-m64' CFLAGS='-m64' #> make Compilation goes well untill: gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/parsetok.o Parser/bitset.o Parser/metagrammar.o Parser/firstsets.o Parser/grammar.o Parser/pgen.o Objects/obmalloc.o Python/mysnprintf.o Parser/tokenizer_pgen.o Parser/printgrammar.o Parser/pgenmain.o -lpthread -ldl -lutil -o Parser/pgen As you can see, in this specific line we don't have the '-m64' flag, what causes a bunch of errors (all of them due to the absence of '-m64' flag). Ok, so I decided to try with LDFLAGS: #> ./configure --enable-shared --target=powerpc64-unknown-linux BASECFLAGS='-m64' CFLAGS='-m64' LDFLAGS='-m64' #> make Now, the error happens when libpython.so is generated (and the reason is the same: missing '-m64'). Well, now I have a few questions: 1) As you could see above, actually you need CFLAGS in order to compile Python correctly. As far as I could investigate, the reason you need this is because of the tests that are done by configure. Without the CFLAGS, configure will think it's building a 32-bit Python, despite of the '-m64' flag in BASECFLAGS. So, do we need to propagate CFLAGS through Makefile or not? IMHO, we do. 2) Even with CFLAGS and BASECFLAGS set, the compilation fails. Using LDFLAGS makes the compilation process continue a little more, but it still doesn't solve the problem. AFAIK, the reason it doesn't solve the problem is, again, because we are not propagating it through the Makefile. Can you see any different reason? Also, should we propagate LDFLAGS through Makefile? IMHO, we should. Ohh, before I forget: compilation succeeds if we use only CC='gcc -m64'. But again, I don't think this is a solution for this issue :-). _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1628484> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Sérgio Durigan Júnior <[EMAIL PROTECTED]> added the comment: Hi Martin, On Mon, 2008-04-14 at 20:04 +, Martin v. Löwis wrote: > Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > > > This is what you get when you try to build a 64-bit Python on a biarch > > machine (64-bit kernel, 32-bit userspace), using a gcc that generates > > natively 32-bit objects (therefore, you *must* pass the '-m64' option > > for the compiler): > > Or you install an additional, different, C compiler that defaults to > AMD64. I cannot do that. Actually, even if I could, I don't think this is the best way to handle this *Python*'s problem. > > 1) As you could see above, actually you need CFLAGS in order to compile > > Python correctly. As far as I could investigate, the reason you need > > this is because of the tests that are done by configure. Without the > > CFLAGS, configure will think it's building a 32-bit Python, despite of > > the '-m64' flag in BASECFLAGS. So, do we need to propagate CFLAGS > > through Makefile or not? IMHO, we do. > > Not necessarily. I think you can achieve the same effect by specifying > CC="gcc -m64" to configure. I know that. But the purpose of CC flag is to define a compiler to be used in the compilation, and not to specify compiler flags (for that, we have CFLAGS). > > Ohh, before I forget: compilation succeeds if we use only CC='gcc -m64'. > > But again, I don't think this is a solution for this issue :-). > > Why not? See above. Regards, _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1628484> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Sérgio Durigan Júnior <[EMAIL PROTECTED]> added the comment: On Tue, 2008-04-15 at 02:01 +, Bob Atkins wrote: > I don't know why you are resisting this change. I took the time to > report the bug, proposed a fix /_*and*_/ contributed the patch that > would make the Python build process more standard relative to the vast > majority of open source packages that use autoconf. I am glad to see > that my patch appears to be generic enough that it works on other > platforms as well. I didn't have to post a bug report let alone > contribute a patch but, I believe strongly that is what open source is > all about. As the maintainer you don't have to accept either the bug or > the patch but, resisting without good cause will discourage further > contributions - certainly from me because I won't waste my time > submitting something when I know that a maintainer of a package is being > closed minded. We do a lot of work with open source software here and it > is our policy to contribute back to the community as much as possible. > However, when we run into a brick wall we quickly give up because we > can't justify the time and effort. As an example, we have completely > suspended all contributions to the asterisk project. We operate a very > large asterisk environment with a lot of fixes and improvements that I > am sure lots of others would love to have but the maintainer's attitude > was that a Sun Solaris platform was not important. What the maintainer > doesn't know is that many of our fixes and changes affect /_*all*_/ > platforms. So now they get nothing from us and the asterisk community as > a whole is deprived of the benefits of our work. I also know that many > others have also suspended contributions for the same reason and as a > result the asterisk package suffers. The resistance on your part to > recognizing this problem and a fix is unjustified. Bob just took the words from my mouth. Martin, with all respect, your resistance in accepting this patch is making things much harder that they really are. The main point here is that this pacth actually *doesn't* break anything in Python! Please, take a time to consider our proposal. Thanks, _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1628484> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
