[issue7308] Named group regex error
New submission from Stefan Sonnenberg-Carstens
stefan.sonnenb...@pythonmeister.com:
import re
p = re.compile(r'(P?quotedstring([^]*))')
p.match('Hallo')
p = re.compile(r'([^]*)')
p.match('Hallo')
_sre.SRE_Match object at 0x0197F758
p.match('Hallo').group()
'Hallo'
import sys
sys.version
'2.6.3 (r263:75183, Oct 5 2009, 14:41:55) [MSC v.1500 32 bit (Intel)]'
When I use a named group like above, the regex does not match.
It otherwise does.
I could not find a hint in the docs, so I guess this behaviour is
not intended.
--
components: Interpreter Core, Library (Lib)
messages: 95152
nosy: pythonmeister
severity: normal
status: open
title: Named group regex error
type: behavior
versions: Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7308
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3233] Timestamp stored in ZIP file not correct ?
New submission from Stefan Sonnenberg-Carstens [EMAIL PROTECTED]: Given the attached source, I can produce these results: [EMAIL PROTECTED] ~]$ python ziptest.py Start 10:05:54 ZIP stored mtime: (2008, 6, 29, 10, 5, 54) Original mtime: (2008, 6, 29, 10, 5, 54) Duration 0.00291705131531 Stop 10:05:54 -- Start 10:05:55 ZIP stored mtime: (2008, 6, 29, 10, 5, 54) Original mtime: (2008, 6, 29, 10, 5, 55) Duration 0.00302505493164 Stop 10:05:55 -- Start 10:05:56 ZIP stored mtime: (2008, 6, 29, 10, 5, 56) Original mtime: (2008, 6, 29, 10, 5, 56) Duration 0.00260186195374 Stop 10:05:56 -- Start 10:05:57 ZIP stored mtime: (2008, 6, 29, 10, 5, 56) Original mtime: (2008, 6, 29, 10, 5, 57) Duration 0.00173997879028 Stop 10:05:57 -- Start 10:05:58 ZIP stored mtime: (2008, 6, 29, 10, 5, 58) Original mtime: (2008, 6, 29, 10, 5, 58) Duration 0.00218915939331 Stop 10:05:58 -- Start 10:05:59 ZIP stored mtime: (2008, 6, 29, 10, 5, 58) Original mtime: (2008, 6, 29, 10, 5, 59) Duration 0.00273489952087 Stop 10:05:59 -- Start 10:06:00 ZIP stored mtime: (2008, 6, 29, 10, 6, 0) Original mtime: (2008, 6, 29, 10, 6, 0) Duration 0.00237393379211 Stop 10:06:00 -- Start 10:06:01 ZIP stored mtime: (2008, 6, 29, 10, 6, 0) Original mtime: (2008, 6, 29, 10, 6, 1) Duration 0.00279211997986 Stop 10:06:01 -- Start 10:06:02 ZIP stored mtime: (2008, 6, 29, 10, 6, 2) Original mtime: (2008, 6, 29, 10, 6, 2) Duration 0.00237607955933 Stop 10:06:02 -- Start 10:06:03 ZIP stored mtime: (2008, 6, 29, 10, 6, 2) Original mtime: (2008, 6, 29, 10, 6, 3) Duration 0.0018618106842 Stop 10:06:03 -- I also printed the duration to see if it passes from one second to another. It doesn't. The behaviour is the same with ZIP_STORED as storage type. -- components: Library (Lib) files: ziptest.py messages: 68934 nosy: pythonmeister severity: normal status: open title: Timestamp stored in ZIP file not correct ? type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file10769/ziptest.py ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3233 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3233] Timestamp stored in ZIP file not correct ?
Stefan Sonnenberg-Carstens [EMAIL PROTECTED] added the comment: I changed the script a bit, so that the txt file is not getting recreated every time. It gives: [EMAIL PROTECTED] ~]$ python ziptest.py Start 10:15:05 ZIP stored mtime: (2008, 6, 29, 10, 15, 4) Original mtime: (2008, 6, 29, 10, 15, 5) Duration 0.00438690185547 Stop 10:15:05 -- Start 10:15:06 ZIP stored mtime: (2008, 6, 29, 10, 15, 4) Original mtime: (2008, 6, 29, 10, 15, 5) Duration 0.00189399719238 Stop 10:15:06 -- Start 10:15:07 ZIP stored mtime: (2008, 6, 29, 10, 15, 4) Original mtime: (2008, 6, 29, 10, 15, 5) Duration 0.00167894363403 Stop 10:15:07 -- Start 10:15:08 ZIP stored mtime: (2008, 6, 29, 10, 15, 4) Original mtime: (2008, 6, 29, 10, 15, 5) Duration 0.00195598602295 Stop 10:15:08 -- Start 10:15:09 ZIP stored mtime: (2008, 6, 29, 10, 15, 4) Original mtime: (2008, 6, 29, 10, 15, 5) Duration 0.0136680603027 Stop 10:15:09 -- Start 10:15:10 ZIP stored mtime: (2008, 6, 29, 10, 15, 4) Original mtime: (2008, 6, 29, 10, 15, 5) Duration 0.00206613540649 Stop 10:15:10 -- Start 10:15:11 ZIP stored mtime: (2008, 6, 29, 10, 15, 4) Original mtime: (2008, 6, 29, 10, 15, 5) Duration 0.00191879272461 Stop 10:15:11 -- Start 10:15:12 ZIP stored mtime: (2008, 6, 29, 10, 15, 4) Original mtime: (2008, 6, 29, 10, 15, 5) Duration 0.00196504592896 Stop 10:15:12 -- Start 10:15:13 ZIP stored mtime: (2008, 6, 29, 10, 15, 4) Original mtime: (2008, 6, 29, 10, 15, 5) Duration 0.00182104110718 Stop 10:15:13 -- Start 10:15:14 ZIP stored mtime: (2008, 6, 29, 10, 15, 4) Original mtime: (2008, 6, 29, 10, 15, 5) Duration 0.0369889736176 Stop 10:15:14 -- Added file: http://bugs.python.org/file10770/ziptest.py ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3233 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1603] Wanted behaviour ?
New submission from Stefan Sonnenberg-Carstens:
a = {}
a['a'] = [1,2,3,4,5]
a['b'] = [1,2,3,4,5]
a['c'] = [1,2,3,4,5]
for k in a.keys():
... print a[k]
... for t in a[k]:
... del a[k][a[k].index(t)]
... print a[k]
...
[1, 2, 3, 4, 5]
[2, 3, 4, 5]
[2, 4, 5]
[2, 4]
[1, 2, 3, 4, 5]
[2, 3, 4, 5]
[2, 4, 5]
[2, 4]
[1, 2, 3, 4, 5]
[2, 3, 4, 5]
[2, 4, 5]
[2, 4]
Does this make sense ?
--
messages: 58488
nosy: pythonmeister
severity: normal
status: open
title: Wanted behaviour ?
type: behavior
versions: Python 2.3
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1603
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1405] Garbage collection not working correctly in Python 2.3
Stefan Sonnenberg-Carstens added the comment: No, I can't. As many Front Arena Developers on the 1.6/2.0/2.1/2.2 can't. Python 2.4 will be in Front Arena 4.0. Lightyears away from here. Same behaviour seen under Solaris 10 / Python 2.5.1 -- versions: +Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1405 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1405] Garbage collection not working correctly in Python 2.3
New submission from Stefan Sonnenberg-Carstens: when running this script: aList = [] for i in xrange(5E5): aList += [[]] for j in xrange(10): aList[-1].append([]) del aList It does not give back the memory even a import gc gc.collect() afterwards does not do it. In Python 2.5 the memory is freed again correctly, at least under Windows. The problem came up, because I was parsing a CSV file of 50 MB which resulted in memory usage of more than 500 MB. -- components: Interpreter Core messages: 57256 nosy: pythonmeister severity: urgent status: open title: Garbage collection not working correctly in Python 2.3 type: resource usage versions: Python 2.3 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1405 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1366] popen spawned process may not write to stdout under windows
Stefan Sonnenberg-Carstens added the comment: the popen call does not redirect stderr. If you do something like 2null (windows) or 2/dev/null (*nix) it will _never_ get printed. If you want to have stderr stdout getting in via popen and thus stdout, under *nix and windows you would do that: command 21 It is not popen to blame. See this for reference: http://netbsd.gw.com/cgi-bin/man-cgi?popen++NetBSD-current -- nosy: +pythonmeister __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1366 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1398] Can't pickle partial functions
Stefan Sonnenberg-Carstens added the comment: You are using an old protocol version pickle.dumps(partial_f,2) does the trick: pickle.dumps(partial_f,2) '\x80\x02cfunctools\npartial\nq\x00)\x81q\x01}q\x02b.' -- nosy: +pythonmeister __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1398 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1279] os.system() oddity under Windows XP SP2
New submission from Stefan Sonnenberg-Carstens: When doing such os.system(a command wich writes a outfile) f = open(the file the command before wrote) the file is empty. If I do this: os.popen(a command wich writes a outfile) f = open(the file the command before wrote) everything is fine -- components: Interpreter Core messages: 56439 nosy: pythonmeister severity: major status: open title: os.system() oddity under Windows XP SP2 type: behavior versions: Python 2.3 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1279 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1159] os.getenv() not updated after external module uses C putenv()
Stefan Sonnenberg-Carstens added the comment: As per the document and my simple test (on Linux), os.putenv() does not update os.environ. I think, it should update it. What would be the benefit ? -- nosy: +pythonmeister __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1159 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1159] os.getenv() not updated after external module uses C putenv()
Stefan Sonnenberg-Carstens added the comment: I'd like to see perl/ruby behaviour: an dict (os.environ), nothing more (perl %ENV,ruby $ENV). Get rid of setenv/putenv at all. 3.0a1 has even more: There is os.environ (a dict), os.[put|get]env() and os.environ.putenv() __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1159 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1141] reading large files
Stefan Sonnenberg-Carstens added the comment: Perhaps this is an issue of line separation ? Could you provide the output of wc -l on a *NIX box ? And, could you try with this code: import sys print(sys.version_info) import time print (time.localtime()) fichin=open(r'D:\pythons\16s\total_gb_161_16S.gb') start = time.time() for i,li in enumerate(fichin): if i%100==0 and i0: print (i,start-time.time()) fichin.close() print(i) print(start-time.time()) Thx -- nosy: +pythonmeister __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1141 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1141] reading large files
Stefan Sonnenberg-Carstens added the comment:
Sorry, this way:
import sys
print(sys.version_info)
import time
print (time.strftime('%Y-%m-%d %H:%M:%S'))
fichin=open(r'D:\pythons\16s\total_gb_161_16S.gb')
start = time.time()
for i,li in enumerate(fichin):
if i%100==0 and i0:
print (i,time.time()-start)
fichin.close()
print(i)
print(time.time()-start)
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1141
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1142] code sample showing errors reading large files with py 2.5
Stefan Sonnenberg-Carstens added the comment:
Error confirmed for this python:
Python 3.0a1 (py3k, Sep 10 2007, 22:45:51)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
See this:
[EMAIL PROTECTED]:~$ python2.4 large_io.py
(2, 4, 4, 'final', 0)
2007-09-10 21:41:52
(500, 14.321661949157715)
(1000, 30.311280965805054)
(1500, 45.24985408782959)
(2000, 59.537726879119873)
(2500, 74.075110912322998)
(3000, 87.76087498664856)
(3500, 104.54858303070068)
(4000, 121.84645009040833)
(4500, 137.88236308097839)
(5000, 155.42996501922607)
(5500, 171.81011009216309)
(6000, 188.44834208488464)
(6500, 204.46978211402893)
(7000, 218.81346702575684)
(7500, 232.86778998374939)
(8000, 246.6789391040802)
(8500, 260.89796900749207)
('total lines written ', 85014960)
(85014960, 260.94281101226807)
**
(500, 14.598887920379639)
(1000, 29.428265810012817)
(1500, 44.457981824874878)
(2000, 60.351485967636108)
(2500, 79.3228759765625)
(3000, 94.667810916900635)
(3500, 110.35149884223938)
(4000, 126.19746398925781)
(4500, 141.83787989616394)
(5000, 157.46236801147461)
(5500, 173.10227298736572)
(6000, 188.19510197639465)
(6500, 197.369295835495)
(7000, 206.41998481750488)
(7500, 215.53365993499756)
(8000, 224.55904102325439)
(8500, 233.75891900062561)
('total lines read ', 85014960)
494.727725029
[EMAIL PROTECTED]:~$ python3.0 large_io.py
(3, 0, 0, 'alpha', 1)
2007-09-10 21:50:53
500 194.725461006
Tasks: 144 total, 3 running, 141 sleeping, 0 stopped, 0 zombie
Cpu(s): 50.2%us, 1.3%sy, 0.0%ni, 48.3%id, 0.0%wa, 0.2%hi, 0.0%si,
0.0%st
Mem: 1026804k total, 846416k used, 180388k free, 7952k buffers
Swap: 1028152k total,66576k used, 961576k free, 679032k cached
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
28778 stefan25 0 7800 3552 1596 R 100 0.3 6:01.48 python3.0
--
nosy: +pythonmeister
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1142
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1142] code sample showing errors reading large files with py 2.5/3.0
Changes by Stefan Sonnenberg-Carstens: -- components: +Interpreter Core title: code sample showing errors reading large files with py 2.5 - code sample showing errors reading large files with py 2.5/3.0 versions: +Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1142 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1142] code sample showing errors reading large files with py 2.5/3.0
Stefan Sonnenberg-Carstens added the comment:
I can confirm that under Linux (Linux nx6310 2.6.22-1-mepis-smp #1 SMP
PREEMPT Wed Sep 5 22:23:08 EDT 2007 i686 GNU/Linux, SimplyMepis 7.0b3)
1. using Python 3.0a1 is _very_ slow
2. it eats all your cpu (see my post)
I did not take the time to wait for the program to finish with 3.0a1,
as my patience is limited. I don't think it would silently drop lines,
as the windows version.
To see if flushing matters, I'll try this later:
import sys
print(sys.version_info)
import time
print (time.strftime('%Y-%m-%d %H:%M:%S'))
liste=[]
start = time.time()
fichout=open('test.txt','w')
for i in xrange(85014961):
if i%500==0 and i0:
print (i,time.time()-start)
fichout.write(str(i)+' '*59+'\n')
fishout.flush()
fichout.close()
print ('total lines written ',i)
print (i,time.time()-start)
print ('*'*50)
fichin=open('test.txt')
start3 = time.time()
for i,li in enumerate(fichin):
if i%500==0 and i0:
print (i,time.time()-start3)
fichin.close()
print ('total lines read ',i)
print(time.time()-start)
I've seen a case lately on Windows XP SP2 with Python 2.3, where a
college of mine wrote some files he read from a zip file to disk.
Before the close() he also had to flush() the written files
explicitly, otherwise he was not able to rename them afterwards.
His first approach was time.sleep(30), which was not an option.
I'll come back, if I ran the code under Windows.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1142
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1134] Parsing a simple script eats all of your memory
Stefan Sonnenberg-Carstens added the comment: Same under Linux with Python 3.0a1. Eats all cpu + memory -- nosy: +pythonmeister __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1134 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1125] bytes.split shold have same interface as str.split, or different name
Stefan Sonnenberg-Carstens added the comment: IMHO I also aggree that strings and bytes (list of bytes) should have the same interface. It is common sense that talking about strings most programmers think of a list of bytes composing it (char *). So the abbreviation should also hold true with python. -- nosy: +pythonmeister __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1125 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1129] OpenSSL detection broken for Python 3.0a1
New submission from Stefan Sonnenberg-Carstens: In line 618 the comparison must be this: if (openssl_ver = 0x00908000): otherwise there are complaints about not being able to build the _sha256 and _sha512 modules, even if OpenSSL = 0.9.8 is installed, as in my case. -- components: Build messages: 55739 nosy: pythonmeister severity: major status: open title: OpenSSL detection broken for Python 3.0a1 type: compile error versions: Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1129 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1129] OpenSSL detection broken for Python 3.0a1
Stefan Sonnenberg-Carstens added the comment:
Patch attached:
--- setup.py2007-09-07 16:08:05.0 -0400
+++ ../Python-3.0a1_SSC/setup.py2007-09-07 16:07:31.0 -0400
@@ -613,7 +613,7 @@
else:
missing.append('_hashlib')
-if (openssl_ver 0x00908000):
+if (openssl_ver = 0x00908000):
# OpenSSL doesn't do these until 0.9.8 so we'll bring our
own hash
exts.append( Extension('_sha256', ['sha256module.c']) )
exts.append( Extension('_sha512', ['sha512module.c']) )
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1129
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1126] file.fileno and file.isatty() should be implementable by any file like object
Stefan Sonnenberg-Carstens added the comment: You are free to do what you want. Reasons for not implementing fileno and isatty are: - fileno should be an integer pointing to a real file, so that low-level functions in libc can handle that. Can you provide such ? (see http://netbsd.gw.com/cgi-bin/man-cgi?open++NetBSD-current) - duck-typing / there must be a difference to real files in the first sense -- nosy: +pythonmeister __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1126 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
