[ANN] TinyMk 0.2 Release
TinyMk is a small, single-file make tool written in Python. You write your build files as a Python script that imports TinyMk. It's small enough and licensed so that you can distribute it with your project. See the GitHub page at https://github.com/kirbyfan64/tinymk. -- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated. -- https://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
unittest_expander 0.3.0 released
I am pleased to announce the release of unittest_expander 0.3.0.
unittest_expander is a MIT-licensed Python library that provides
flexible and easy-to-use tools to parameterize your unit tests,
especially those based on unittest.TestCase.
The library is compatibile with Python 2.6, 2.7, 3.2, 3.3 and 3.4, and
does not depend on any external packages (uses only the Python standard
library).
Simple usage example:
import unittest
from unittest_expander import expand, foreach, param
@expand
class TestSomething(unittest.TestCase):
@foreach(
'Foo',
('Foo', 43),
param('Foo', spam=44),
param(foo='Bar', spam=45).label('with bar'),
empty=param(foo='', spam=46),
)
def test_it(self, foo, spam=42, label=None):
assert foo in ('Foo', 'Bar', '')
assert 42 = spam = 46
if label == 'with bar':
assert foo == 'Bar' and spam == 45
if label == 'empty':
assert foo == '' and spam == 46
This is only a fraction of the possibilities the unittest_expander
library provides.
Homepage: https://github.com/zuo/unittest_expander
PyPI: https://pypi.python.org/pypi/unittest_expander
Documentation: http://unittest-expander.readthedocs.org/en/latest/
Cheers,
Jan Kaliszewski (zuo)
--
https://mail.python.org/mailman/listinfo/python-announce-list
Support the Python Software Foundation:
http://www.python.org/psf/donations/
Re: Unicode in cgi-script with apache2
Denis McMahon wrote:
From your other message, the error appears to be a python error on
reading the input file. For some reason python seems to be trying to
interpret the file it is reading as ascii.
Oh!!! /facepalm
I think you've got it. I've been assuming the problem was on *writing* the
line. That's because the OP was insistent that the line failing was
[quoting Dominique]
The problem is, when python 'prints' to the apache interface, it
translates the string to ascii.
but if you read the traceback, you're right, the problem is *reading* the
file, not printing:
[Sat Aug 16 23:12:42.158326 2014] [cgi:error] [pid 29327] [client
119.63.193.196:0] AH01215: Traceback (most recent call last):
[Sat Aug 16 23:12:42.158451 2014] [cgi:error] [pid 29327] [client
119.63.193.196:0] AH01215: File /var/www/cgi-python/index.html,
line 12, in module
[Sat Aug 16 23:12:42.158473 2014] [cgi:error] [pid 29327] [client
119.63.193.196:0] AH01215: for line in f:
That's the line which is failing, reading the file. Which is then *decoded*.
Files contain bytes, which have to be decoded into text, and the decode is
assuming ASCII:
[Sat Aug 16 23:12:42.158526 2014] [cgi:error] [pid 29327] [client
119.63.193.196:0] AH01215: File
/usr/lib/python3.4/encodings/ascii.py, line 26, in decode
[Sat Aug 16 23:12:42.158569 2014] [cgi:error] [pid 29327] [client
119.63.193.196:0] AH01215: return codecs.ascii_decode(input,
self.errors)[0]
[Sat Aug 16 23:12:42.158663 2014] [cgi:error] [pid 29327] [client
119.63.193.196:0] AH01215: UnicodeDecodeError: 'ascii' codec can't
decode byte 0xc3 in position 1791: ordinal not in range(128)
I wonder if specifying the binary data parameter and / or utf-8 encoding
when opening the file might help.
We don't really know what encoding the index.html file is encoded in. It
might be Latin-1, or cp-1252, or some other legacy encoding. But let's
assume it's UTF-8.
So why is Dominque's script reading it in ASCII? That's the key question. I
have a sinking feeling that Apache may be running Python as a subprocess
with the C locale, maybe. I don't know enough about cgi to be more than
just guessing.
Dominique, if you write:
f = open(/var/www/cgi-data/index.html, r, encoding='utf-8')
the problem should go away (assuming index.html is valid UTF-8). If it
doesn't, there's a very strange bug somewhere.
Please try that, and see if it fixes the problem, or if the error goes to a
different line.
eg:
f = open( /var/www/cgi-data/index.html, rb )
No, you don't want that, since then reading the file will return bytes, not
text. Although I suppose the OP might just commit to using bytes
everywhere. Yuck.
f = open( /var/www/cgi-data/index.html, rb, encoding=utf-8 )
That makes no sense. If you're reading in binary mode, there's no encoding.
Every byte represents itself.
f = open( /var/www/cgi-data/index.html, r, encoding=utf-8 )
That's the bunny!
If you just want to hide the problem without fixing the underlying cause,
add an argument errors=replace, which is ugly but at least lets you move
on:
py b = Hello ë ü world.encode('utf-8')
py print(b.decode('ascii', errors='replace'))
Hello �� �� world
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: Unicode in cgi-script with apache2
Wow, everybody keeps on chewing on this problem. As a bonus, I've
reconfigured my server to do some testings.
http://cloudserver.ramaekers-stassart.be/test.html = is the file I want
to read. Going to this url displays the file...
http://cloudserver.ramaekers-stassart.be/cgi-python/encoding1 = is the
cgi-script of this test
http://cloudserver.ramaekers-stassart.be/wsgi = is the wsgi sollution
(but for now it just says 'Hello world'...)
This configuration-
dominique@cloudserver:/var/www/cgi-python$ cat /etc/default/locale
LANG=en_US.UTF-8
LANGUAGE=en_US:
dominique@cloudserver:/var/www/cgi-python$ cat
/etc/apache2/sites-enabled/000-default.conf
VirtualHost *:80
ServerAdmin domini...@ramaekers-stassart.be
WSGIScriptAlias /wsgi /var/www/wsgi/application
Directory /var/www/wsgi
Order allow,deny
Allow from all
/Directory
DocumentRoot /var/www/html
ScriptAlias /cgi-python /var/www/cgi-python/
Directory /var/www/cgi-python
Options ExecCGI
SetHandler cgi-script
/Directory
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
/VirtualHost
dominique@cloudserver:/var/www/cgi-python$ cat encoding1
#!/usr/bin/env python3
print(Content-Type: text/html)
print(Cache-Control: no-cache, must-revalidate)# HTTP/1.1
print(Expires: Sat, 26 Jul 1997 05:00:00 GMT) # Date in the past
print()
f = open(/var/www/html/test.html, r)
for line in f:
print(line,end='')
dominique@cloudserver:/var/www/cgi-python$ cat ../html/test.html
!DOCTYPE html
html lang=en
head
meta charset=UTF-8
titleTesting my cgi.../title
/head
body
pOk, Testing my cgi... Lets try some characters: é ë ü/p
/body
/html
dominique@cloudserver:/var/www/cgi-python$ file ../html/test.html
../html/test.html: HTML document, UTF-8 Unicode text
-Start test--
In brower: http://cloudserver.ramaekers-stassart.be/test.html = page
displays ok (try it yourself...)
In terminal: = all go's wel
dominique@cloudserver:/var/www/cgi-python$ ./encoding1
Content-Type: text/html
Cache-Control: no-cache, must-revalidate
Expires: Sat, 26 Jul 1997 05:00:00 GMT
!DOCTYPE html
html lang=en
head
meta charset=UTF-8
titleTesting my cgi.../title
/head
body
pOk, Testing my cgi... Lets try some characters: é ë ü/p
/body
/html
In the browser (firefox):
http://cloudserver.ramaekers-stassart.be/cgi-python/encoding1 = gives a
blank page!
The error log says:
root@cloudserver:~# cat /var/log/apache2/error.log | tail -n 6
[Sun Aug 17 11:09:21.102003 2014] [cgi:error] [pid 32146] [client
84.194.120.161:36707] AH01215: Traceback (most recent call last):
[Sun Aug 17 11:09:21.102129 2014] [cgi:error] [pid 32146] [client
84.194.120.161:36707] AH01215: File /var/www/cgi-python/encoding1,
line 7, in module
[Sun Aug 17 11:09:21.102149 2014] [cgi:error] [pid 32146] [client
84.194.120.161:36707] AH01215: for line in f:
[Sun Aug 17 11:09:21.102201 2014] [cgi:error] [pid 32146] [client
84.194.120.161:36707] AH01215: File
/usr/lib/python3.4/encodings/ascii.py, line 26, in decode
[Sun Aug 17 11:09:21.102243 2014] [cgi:error] [pid 32146] [client
84.194.120.161:36707] AH01215: return codecs.ascii_decode(input,
self.errors)[0]
[Sun Aug 17 11:09:21.102318 2014] [cgi:error] [pid 32146] [client
84.194.120.161:36707] AH01215: UnicodeDecodeError: 'ascii' codec can't
decode byte 0xc3 in position 162: ordinal not in range(128)
--Conclusion-
In my current configuration, the bug is recreated!!!
---Test 2: new configuration-
I change the line f = open(/var/www/html/test.html, r) into f =
open(/var/www/html/test.html, r, encoding=utf-8) and save the
script as encoding2
In the terminal: = All ok
In the browser: = blank page!!!
Error log in apache:
root@cloudserver:~# cat /var/log/apache2/error.log | tail -n 4
[Sun Aug 17 11:13:47.372353 2014] [cgi:error] [pid 32147] [client
84.194.120.161:36711] AH01215: Traceback (most recent call last):
[Sun Aug 17 11:13:47.372461 2014] [cgi:error] [pid 32147] [client
84.194.120.161:36711] AH01215: File /var/www/cgi-python/encoding2,
line 8, in module
[Sun Aug 17 11:13:47.372483 2014] [cgi:error] [pid 32147] [client
84.194.120.161:36711] AH01215: print(line,end='')
[Sun Aug 17 11:13:47.372572 2014] [cgi:error] [pid 32147] [client
84.194.120.161:36711] AH01215: UnicodeEncodeError: 'ascii' codec can't
encode character '\\xe9' in position 51: ordinal not in range(128)
-Conclusion--
Steven was right. It was a read error = with encoding2 script the file
is read in UTF-8. Dough, I find it strange. The file is in UTF-8 and
Python3 has UTF-8 as standard. But reading the file is fixed.
Now the writing is still broken
Here are some tests hinted before:
Tip from Steven = getting the encoding:
Re: Unicode in cgi-script with apache2
Dominique Ramaekers wrote: Putting the lines in my apache config: AddDefaultCharset UTF-8 SetEnv PYTHONIOENCODING utf-8 Cleared my brower-cache... No change. Did you restart the apache? -- https://mail.python.org/mailman/listinfo/python-list
Pythoncom IEnum weird behaviour
I have a COM server implemented in Python. I've created
the following object implementing IEnum to automatically
wrap the sequence elements in PyIDispatch objects:
from win32com.server.util import ListEnumerator
class Iterator(ListEnumerator):
def Next(self, count):
items = ListEnumerator.Next(self, count)
print Server.Iterator: items =, items
result = map(autowrap, items)
print Server.Iterator: result =, result
return result
where autowrap() is a function that uses various
strategies to wrap different types of objects.
When I try to iterate over one of these, I get this:
Server.Iterator: items = [Duck.Leg object at 0x01803AF0]
Server.Iterator: result = [PyIDispatch at 0x0149BBB0 with obj at 0x01403058]
PyGEnumVariant::Next got a bad return value
Traceback (most recent call last):
File F:\AFICom\AFICom2\Tests\test_nesting.py, line 14, in module
for leg in legs:
File E:\Python27\lib\site-packages\win32com\client\util.py, line 84, in
next
return _get_good_object_(self._iter_.next(), resultCLSID = self.resultCLSID)
TypeError: Cant convert vectors!
I don't understand what's happening here. The Next got a bad return value
message seems to be coming from PyGEnumVARIANT::Next in PyGEnumVariant.cpp.
The only ways to get there seem to be if your Next() method doesn't
return a sequence, or getting its length fails, or getting an item from
it fails. But as far as I can tell, I'm returning a perfectly good
list object, so I can't see how any of those things can happen.
I also don't know why I'm not getting the COMError exception set by
that branch of the code:
error:
PyErr_Clear();// just in case
PyCom_LogF(PyGEnumVariant::Next got a bad return value);
Py_DECREF(result);
return PyCom_SetCOMErrorFromSimple(E_FAIL, IID_IEnumVARIANT, Next() did not
return a sequence of objects);
The Cant convert vectors message is puzzling as well. That comes from
the following piece of code in PyCom_PyObjectFromVariant in oleargs.cpp:
/* ### note: we shouldn't see this, it is illegal in a VARIANT */
if (V_ISVECTOR(var)) {
return OleSetTypeError(_T(Cant convert vectors!));
}
Anyone have any idea what's happening? Is there something wrong with
my Next() method? Is there a bug in the win32com C++ code?
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Re: Unicode in cgi-script with apache2
Yes, even a restart not just reload. I Also put it in the section virtualHost as in the main apache2.conf Op 17-08-14 om 13:04 schreef Peter Otten: Dominique Ramaekers wrote: Putting the lines in my apache config: AddDefaultCharset UTF-8 SetEnv PYTHONIOENCODING utf-8 Cleared my brower-cache... No change. Did you restart the apache? -- https://mail.python.org/mailman/listinfo/python-list
Re: Unicode in cgi-script with apache2
As I suspected, if I check the used encoding in wsgi I get:
ANSI_X3.4-1968
I found you can define the coding of the script with a special comment:
# -*- coding: utf-8 -*-
Now I don't get an error but my special chars still doesn't display well.
The script:
# -*- coding: utf-8 -*-
import sys
def application(environ, start_response):
status = '200 OK'
output = 'Hello World! é ü à ũ'
#output = sys.getfilesystemencoding() #1
response_headers = [('Content-type', 'text/plain'),
('Content-Length', str(len(output)))]
start_response(status, response_headers)
return [output]
Gives in the browser as output:
Hello World! é ü à ũ
And if I check the encoding with the python script (uncommenting line
#1), I still get ANSI_X3.4-1968
This is really getting on my nerves.
Op 17-08-14 om 13:04 schreef Peter Otten:
Dominique Ramaekers wrote:
Putting the lines in my apache config:
AddDefaultCharset UTF-8
SetEnv PYTHONIOENCODING utf-8
Cleared my brower-cache... No change.
Did you restart the apache?
--
https://mail.python.org/mailman/listinfo/python-list
Re: Unicode in cgi-script with apache2
On 17/08/2014 13:02, Dominique Ramaekers wrote: if style == TOP_POSTING: *plonk* -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Why Python 4.0 won't be like Python 3.0
A blog from Nick Coghlan http://www.curiousefficiency.org/posts/2014/08/python-4000.html that should help put a few minds to rest. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Unicode in cgi-script with apache2
Dominique Ramaekers wrote:
As I suspected, if I check the used encoding in wsgi I get:
ANSI_X3.4-1968
That's another name for ASCII.
I found you can define the coding of the script with a special comment:
# -*- coding: utf-8 -*-
Be careful. That just tells Python what encoding the source code file is in.
It is not used by print(), or reading/writing files, just when the compiler
reads the source code.
Now I don't get an error but my special chars still doesn't display well.
The script:
# -*- coding: utf-8 -*-
import sys
def application(environ, start_response):
status = '200 OK'
output = 'Hello World! é ü à ũ'
#output = sys.getfilesystemencoding() #1
response_headers = [('Content-type', 'text/plain'),
('Content-Length', str(len(output)))]
start_response(status, response_headers)
return [output]
Gives in the browser as output:
Hello World! é ü à ũ
That looks like ordinary moji-bake. Your Python script takes the text
string 'Hello World! é ü à ũ', which in UTF-8 gives you bytes:
py 'Hello World! é ü à ũ'.encode('utf-8')
b'Hello World! \xc3\xa9 \xc3\xbc \xc3\xa0 \xc5\xa9'
Decoding back using latin-1 gives:
py 'Hello World! é ü à ũ'.encode('utf-8').decode('latin1')
'Hello World! é ü Ã\xa0 Å©'
which appears to be exactly what you have. Why Latin-1 instead of ASCII?
Because the process has to output *something*, and Latin-1 is sometimes
called extended ASCII.
I'm starting to fear a bug in Python 3.4, but since I have almost no
knowledge about wsgi and cgi, I can't be sure that this isn't just normal
expected behaviour :-(
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: Unicode in cgi-script with apache2
Dominique Ramaekers wrote:
As I suspected, if I check the used encoding in wsgi I get:
ANSI_X3.4-1968
I found you can define the coding of the script with a special comment:
# -*- coding: utf-8 -*-
Now I don't get an error but my special chars still doesn't display well.
The script:
# -*- coding: utf-8 -*-
import sys
def application(environ, start_response):
status = '200 OK'
output = 'Hello World! é ü à ũ'
#output = sys.getfilesystemencoding() #1
response_headers = [('Content-type', 'text/plain'),
('Content-Length', str(len(output)))]
start_response(status, response_headers)
return [output]
Gives in the browser as output:
Hello World! é ü à ũ
That's UTF-8 interpreted as Latin-1. Try specifying the charset in the
header:
...
response_headers = [('Content-type', 'text/plain; charset=utf-8'),
...
And if I check the encoding with the python script (uncommenting line
#1), I still get ANSI_X3.4-1968
--
https://mail.python.org/mailman/listinfo/python-list
Re: Unicode in cgi-script with apache2
Dominique Ramaekers wrote: And if I check the encoding with the python script (uncommenting line #1), I still get ANSI_X3.4-1968 That should not matter as long as print(os.environ.get(PYTHONIOENCODING)) prints UTF-8 If you do get the correct PYTHONIOENCODING you should be able to replace the corresponding SetEnv with SetEnv LANG en_US.UTF-8 or similar. If you don't get the expected value the SetEnv is probably not in the right place. In my experiments I put it into /etc/apache2/sites-enabled/000-default.conf in an apache installation I think I have not tinkered with before ;) While looking around in the apache configuration I also found the file /etc/apache2/envvars. Here's an excerpt: ## The locale used by some modules like mod_dav export LANG=C ## Uncomment the following line to use the system default locale instead: #. /etc/default/locale export LANG If you uncomment the line . /etc/default/locale and replace SetEnv LANG en_US.UTF-8 with PassEnv LANG you should get a similar effect assuming your system defaults to UTF-8. -- https://mail.python.org/mailman/listinfo/python-list
GIL detector
Coincidentally after reading Armin Ronacher's criticism of the GIL in Python: http://lucumr.pocoo.org/2014/8/16/the-python-i-would-like-to-see/ I stumbled across this GIL detector script: http://yuvalg.com/blog/2011/08/09/the-gil-detector/ Running it on a couple of my systems, I get these figures: CPython 2.7: 0.8/2 cores CPython 3.3: 1.0/2 cores Jython 2.5: 2.3/4 cores CPython 2.6: 0.7/4 cores CPython 3.3: 0.7/4 cores With IronPython, the script raise an exception. The day will come that even the cheapest, meanest entry-level PC will come standard with 8 cores and the GIL will just be an embarrassment, but today is not that day. I wonder whether Ruby programmers are as obsessive about Ruby's GIL? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: GIL detector
On 17.08.2014 16:21, Steven D'Aprano wrote: Coincidentally after reading Armin Ronacher's criticism of the GIL in Python: http://lucumr.pocoo.org/2014/8/16/the-python-i-would-like-to-see/ Sure that's the right one? The article you linked doesn't mention the GIL. I stumbled across this GIL detector script: http://yuvalg.com/blog/2011/08/09/the-gil-detector/ Running it on a couple of my systems, I get these figures: CPython 2.7: 0.8/2 cores CPython 3.3: 1.0/2 cores Jython 2.5: 2.3/4 cores CPython 2.6: 0.7/4 cores CPython 3.3: 0.7/4 cores CPython 3.4: 0.9/4 cores Cheers, Johannes -- Wo hattest Du das Beben nochmal GENAU vorhergesagt? Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa hidbv3$om2$1...@speranza.aioe.org -- https://mail.python.org/mailman/listinfo/python-list
Re: GIL detector
On Mon, Aug 18, 2014 at 12:21 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: The day will come that even the cheapest, meanest entry-level PC will come standard with 8 cores and the GIL will just be an embarrassment, but today is not that day. I wonder whether Ruby programmers are as obsessive about Ruby's GIL? I'm kinda waiting till I see tons of awesome asyncio code in the wild, but the way I'm seeing things, the world seems to be moving toward a model along these lines: 0) Processes get spawned for any sort of security/protection boundary. Sandboxing Python-in-Python (or any other high level language) just isn't worth the effort. 1) One process, in any high level language, multiplexes requests but uses just one CPU core. 2) Something at a higher level dispatches requests between multiple processes - eg Passenger with Apache. So, if you want to take advantage of your eight cores, you run eight processes, and have Apache spread the load between them. Each process might handle a large number of concurrent requests, but all through async I/O and a single dispatch loop. Even the use of multiple threads seems to be dying out (despite being quite handy when lower-level functions will release the GIL) in favour of the multiple process model. I'm just not sure how, with that kind of model, to have processes interact with each other. It's fine when every request is handled perfectly independently, but what if you want per-user state, and you can't guarantee that one user's requests will all come to the same process? You have to push everything through a single serialized storage vault (probably a database), which is then going to become the bottleneck. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: GIL detector
Johannes Bauer wrote: On 17.08.2014 16:21, Steven D'Aprano wrote: Coincidentally after reading Armin Ronacher's criticism of the GIL in Python: http://lucumr.pocoo.org/2014/8/16/the-python-i-would-like-to-see/ Sure that's the right one? The article you linked doesn't mention the GIL. Search for global interpreter lock, there are at least three references to it. Okay, the post is not *specifically* criticism of the GIL, but of the design decision which makes the GIL necessary. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Module-level functions and the module type
In a class definition, you have explicit state parameters on your functions - 'self': class C: def foo(self, arg): # blah blah At module level, there's equivalent state - the function knows what module it came from - but it's implicit: def foo(arg): # blah blah print(foo.__globals__) How hard would it be to unify these, and make modules into classes? This would then allow stuff like properties, metaclasses, and so on, all with exactly the same semantics as they have in classes. Obviously this would be a huge backward-compatibility break if it happened everywhere, but what I'm looking at here is a way to basically bless this kind of concept: # spam.py class RealSpam: # module contents here import sys sys.modules[__name__] = RealSpam() So the question is: Why is state implicit in one and explicit in the other? Which option is really the better way to do things? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: GIL detector
Steven D'Aprano schrieb am 17.08.2014 um 16:21: I wonder whether Ruby programmers are as obsessive about Ruby's GIL? I actually wonder more whether Python programmers are really all that obsessive about CPython's GIL. Sure, there are always the Loud Guys who speak up when they feel like no-one's mentioned it for too long, but I'd expect the vast majority to be just ok with the status quo and not think about it most of the time. Or, well, think about it when one of the Loud Guys takes the megaphone, but then put their thoughts back in the attic and keep doing their daily work. Personally, I like the GIL. It helps me keep my code simpler and more predictable. I don't have to care about threading issues all the time and can otherwise freely choose the right model of parallelism that suits my current use case when the need arises (and threads are rarely the right model). I'm sure that's not just me. Stefan -- https://mail.python.org/mailman/listinfo/python-list
Re: Module-level functions and the module type
Chris Angelico wrote: In a class definition, you have explicit state parameters on your functions - 'self': class C: def foo(self, arg): # blah blah At module level, there's equivalent state - the function knows what module it came from - but it's implicit: def foo(arg): # blah blah print(foo.__globals__) How hard would it be to unify these, and make modules into classes? There's a difference though: modules are instances of ModuleType. While it's true that classes are instances of type, you cannot instantiate a module instance. This would then allow stuff like properties, metaclasses, and so on, all with exactly the same semantics as they have in classes. Obviously this would be a huge backward-compatibility break if it happened everywhere, but what I'm looking at here is a way to basically bless this kind of concept: # spam.py class RealSpam: # module contents here import sys sys.modules[__name__] = RealSpam() But that is already blessed! You can stick anything you like in sys.modules, and import will accept it. This is been true for a long time: [steve@ando ~]$ python2.4 Python 2.4.3 (#1, Jan 9 2013, 06:49:54) [GCC 4.1.2 20080704 (Red Hat 4.1.2-54)] on linux2 Type help, copyright, credits or license for more information. py import sys py sys.modules['lunch'] = 'spam spam spam' py import lunch py lunch.upper() 'SPAM SPAM SPAM' There is a special meaning to given to None: py sys.modules['breakfast'] = None py import breakfast Traceback (most recent call last): File stdin, line 1, in ? ImportError: No module named breakfast but otherwise you should be able to use anything you like. The tricky part is having a module replace itself on the fly. So the question is: Why is state implicit in one and explicit in the other? Which option is really the better way to do things? Global state is implicit so that we can write code with unqualified variable names, and the current namespace is implicit: # Module m.py x = 1 y = x + 1 instead of this: this.x = 1 this.y = this.x + 1 Also, the interpreter would need to handle this specially, it can't just be a regular variable. If it was, you would need to look it up in an explicitly stated namespace, which is an ordinary variable that needs a namespace... x # Where's the namespace for x? this.x # Where's the namespace for this? this.this.x this.this.this.x this.this.this.this.x ... *Somewhere* there has to be an implicit namespace. Might as well be right at the beginning. But inside class methods we have a problem: class X: def method(): a = b + c We can trivially decide on a rule that a must be a local, but how about b and c? Are they globals or attributes of the instance? Python decided on giving globals (well, actually nonlocals) priority, and requiring an explicit self, so we can write this: def method(self): a = self.b + len(c) instead of this: def method(): locals.a = b + globals.len(globals.c) -- Steven -- https://mail.python.org/mailman/listinfo/python-list
RE: GIL detector
I don't have to care about threading issues all the time and can otherwise freely choose the right model of parallelism that suits my current use case when the need arises (and threads are rarely the right model). I'm sure that's not just me. The sound bite of a loyal Python coder:) If it weren't for these useless threads, you wouldn't have even been able to send that message, let alone do anything on a computer for that matter. That generalization is a bit broad, the argument is pointless when it moves away from a purely technical to an emotionally basis. A failure to separate the two pigeonholes the progress of the language and hides underlying constraints which is what Armins post was trying to bring forward. It's naïve to think the first crack of anything is immune to refactoring. No one said Python doesn't have any merit and I honestly don't know a perfect language that has no need for improvement somewhere. I am sure however that the topic is a concern for many use cases (not all). jlc -- https://mail.python.org/mailman/listinfo/python-list
Re: GIL detector
On Mon, Aug 18, 2014 at 1:26 AM, Stefan Behnel stefan...@behnel.de wrote: I actually wonder more whether Python programmers are really all that obsessive about CPython's GIL. Sure, there are always the Loud Guys who speak up when they feel like no-one's mentioned it for too long, but I'd expect the vast majority to be just ok with the status quo and not think about it most of the time. Or, well, think about it when one of the Loud Guys takes the megaphone, but then put their thoughts back in the attic and keep doing their daily work. Personally, I like the GIL. It helps me keep my code simpler and more predictable. I don't have to care about threading issues all the time and can otherwise freely choose the right model of parallelism that suits my current use case when the need arises (and threads are rarely the right model). I'm sure that's not just me. The GIL doesn't prevent threads, even. It just affects when context switches happen and what can run in parallel. As I've often said, threads make fine sense for I/O operations; although that may start to change - I'm sure the day will come when asyncio is the one obvious way to do multiplexed I/O in Python. The GIL means you can confidently write code that uses CPython's refcounting mechanisms (whether overtly, in an extension module, or implicitly, by just doing standard Python operations), and be confident that internal state won't be corrupted... or, more accurately, be confident that you're not paying a ridiculous performance penalty (even in a single-threaded program) for the guarantee that internal state won't be corrupted. Pike has a similar global lock; so, I believe, does Ruby, and so do several other languages. It's way more efficient than a lot of the alternatives. I can't speak for Ruby, but Pike has had periodic discussions about lessening the global lock's impact (one such way is isolating purely-local objects from those with global references; if an object's referenced only from the execution stack, there's no way for any other thread to see it, ergo it's safe to work with sans locks - considering that a lot of data manipulation will be done in this way, this could give a lot of parallelism), and yet the GIL still exists in Python and Pike, because it really is better than the alternatives - or at least, insufficiently worse to justify the transitional development. We do not have a problem here. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: GIL detector
On Mon, Aug 18, 2014 at 2:01 AM, Joseph L. Casale jcas...@activenetwerx.com wrote: If it weren't for these useless threads, you wouldn't have even been able to send that message, let alone do anything on a computer for that matter. Not sure about that. I think it would be entirely possible to build a computer that has no C threads, just processes (with separate memory spaces) and HLL threads governed by GILs - that is, each process cannot possibly consume more than 100% CPU time. Threads aren't inherently required for anything, but they do make certain jobs easier. When I grew up with threads, multi-core home computers simply didn't exist, so in effect the *entire computer* had a GIL. Threads still had their uses (fast response on thread 0 makes for a responsive GUI, then the heavy processing gets done on a spun-off thread with presumably lower scheduling priority), and that's not changing. Requiring that only one thread of any given process be running at a time is just a minor limitation, and one that I would accept as part of the restrictions of high level languages. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Module-level functions and the module type
On Mon, Aug 18, 2014 at 1:59 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: But inside class methods we have a problem: class X: def method(): a = b + c We can trivially decide on a rule that a must be a local, but how about b and c? Are they globals or attributes of the instance? Python decided on giving globals (well, actually nonlocals) priority, and requiring an explicit self, so we can write this: def method(self): a = self.b + len(c) instead of this: def method(): locals.a = b + globals.len(globals.c) I agree with this, and the C++ way of doing things is fraught with peril. The only way it could even possibly work is with fully-declared instance variables, and that's something Python's not going for :) However, there's no particular reason not to have 'self' as a special name. It's already pretty much reserved for that by convention, so this would just mean that, in a module with an explicit metaclass, 'self' refers to the module object. You'd get something like this: def method(): a = self.b + len(c) which, after all, isn't materially different from your third entry, in that both of them need some kind of implicit namespace, just as your explicit 'this' example from above does. Since this would then also be at module level, it would be reasonable for 'global x' to correspond to 'self.x', which is something that would require a bit more language support. Currently, the version I demonstrated has an extra level of namespacing, which is completely unnecessary. It'd be nice to be able to unify all of that. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
RE: GIL detector
Joseph L. Casale wrote: I don't have to care about threading issues all the time and can otherwise freely choose the right model of parallelism that suits my current use case when the need arises (and threads are rarely the right model). I'm sure that's not just me. The sound bite of a loyal Python coder:) Who are you replying to? Please give attribution when you quote someone. If it weren't for these useless threads, you wouldn't have even been able to send that message, let alone do anything on a computer for that matter. I don't see anyone except you calling threads useless. That's your word. The person you quoted said that threads are rarely the right module, which is not the same. (And probably a bit strong.) However, you are factually wrong. Computers existed for decades before lightweight threads were invented. Computers were capable of networking and messaging decades ago, before the Internet existed, and they did it without threads, supporting hundreds or even thousands of users at a time. They did it with multiple processes, not threads, and today we have the same choice. There are pros and cons to both multithreading and multiprocessing. Those who insist that Python is completely broken because some implementations cannot take advantage of multiple cores from threads have missed the point that you can use a separate process for each core instead. Ironically, using threads for email in Python is probably going to work quite well, since it is limited by I/O and not CPU. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
reg: data visualisation
http://data-analytics.github.io/ Check this out an intresting charts using python scripts as welll, -- *Regards* *Sushanth* *ph : 91-94445 83307* -- https://mail.python.org/mailman/listinfo/python-list
How can I get the timezone time of a location?
The land area of China is 60-degree longitude from west to east.
According to the demarcation of the world time zoning standard,
the land area of China lies between the eastern fifth to ninth time
zones, there are 5 time zones in china in fact.
Currently, all the places in China have adopted the eastern eighth time
zone for the sake of convenience. It is the so-called “/Beijing Time/”.
I knew there is a difference between localtime and timezone time.
Localtime: The official time in a local region (adjusted for location
around the Earth); established by law or custom.
Timezone: Any of the 24 regions of the globe (loosely divided by
longitude) throughout which the same standard time is used.
Timezone time : If location A is belong to timezone X, the time of
timezone X is the location A 's timezone time.
For Urumqi,localtime is the time of east 8 timezone, but timezone time
is the time of east 6 timezone.
How can I get the timezone time of urumqi with python code?
|from datetime import datetime, timedelta
from pytz import timezone
import pytz
tz = pytz.timezone('Asia/Urumqi')
dt= tz.localize(datetime(2002, 10, 27, 6, 0, 0))
fmt = '%Y-%m-%d %H:%M:%S %Z%z'
print(dt.strftime(fmt))
2002-10-27 06:00:00 CST+0800
|
It is a wrong answer,the timezone time is 2002-10-27 04:00:00 +0600
.|2002-10-27 06:00:00 CST+0800| is the localtime for Urumiq(by law in
china).
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 4.0 won't be like Python 3.0
On Aug 17, 2014, at 8:37 AM, Mark Lawrence breamore...@yahoo.co.uk wrote: A blog from Nick Coghlan http://www.curiousefficiency.org/posts/2014/08/python-4000.html that should help put a few minds to rest. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list Definitely a relief. After delving into Python only a few short months ago, everything I was reading suggested 2.x.x. When I switched to another book to continue with my studies, some of the code wasn't working ... welcome to 3.x.x. Needless to say, I'm using 3.4.1 exclusively today unless something bizarre requires me to do otherwise. Thanks for sharing. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 4.0 won't be like Python 3.0
On Mon, Aug 18, 2014 at 9:17 AM, Redge @ Versalytics.com versalyt...@gmail.com wrote: Definitely a relief. After delving into Python only a few short months ago, everything I was reading suggested 2.x.x. When I switched to another book to continue with my studies, some of the code wasn't working ... welcome to 3.x.x. Needless to say, I'm using 3.4.1 exclusively today unless something bizarre requires me to do otherwise. Good move. You should be able to upgrade to 3.4.x safely, and 3.5 fairly safely. Eventually, books about Python 3 will be the more easily found, and you won't have this kind of confusion. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
How to look up historical time zones by date and location (was: How can I get the timezone time of a location?)
luofeiyu elearn2...@gmail.com writes: I knew there is a difference between localtime and timezone time. Localtime: The official time in a local region (adjusted for location around the Earth); established by law or custom. Timezone: Any of the 24 regions of the globe (loosely divided by longitude) throughout which the same standard time is used. That is not what “time zone” means and you're going to continue being confused if you apply that definition. See the consensus definition at URL:https://en.wikipedia.org/wiki/Time_zone. For Urumqi,localtime is the time of east 8 timezone, but timezone time is the time of east 6 timezone. How have you determined these? Who declares “east 6” for Urumqi currently? Why should you expect a timezone database to contain that timezone for current time in that location. By the international time zone database, the time zone for Urumqi is currently “China Standard Time”, UTC+8 hours. That time zone is true for all dates since 1949 to the present day. Are you perhaps asking not about *current* time zone, but time zones at a different point in time? Historical time zones in China have differed URL:https://en.wikipedia.org/wiki/Historical_time_zones_of_China. Those historical time zones are in the standard time zone database, but only apply to specific date ranges. -- \“… no testimony can be admitted which is contrary to reason; | `\ reason is founded on the evidence of our senses.” —Percy Bysshe | _o__)Shelley, _The Necessity of Atheism_, 1811 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
User class binary ops seem too slow (was re: GIL detector)
In a post about CPython's GIL, Steven D'Aprano pointed to Armin
Ronacher's criticism of the internal type slots used for dunder methods.
http://lucumr.pocoo.org/2014/8/16/the-python-i-would-like-to-see/
I found the following interesting.
Since we have an __add__ method the interpreter will set this up in a
slot. So how fast is it? When we do a + b we will use the slots, so here
is what it times it as:
$ python3 -mtimeit -s 'from x import A; a = A(); b = A()' 'a + b'
100 loops, best of 3: 0.256 usec per loop
If we do however a.__add__(b) we bypass the slot system. Instead the
interpreter is looking in the instance dictionary (where it will not
find anything) and then looks in the type's dictionary where it will
find the method. Here is where that clocks in at:
$ python3 -mtimeit -s 'from x import A; a = A(); b = A()' 'a.__add__(b)'
1000 loops, best of 3: 0.158 usec per loop
Can you believe it: the version without slots is actually faster. What
magic is that? I'm not entirely sure what the reason for this is,
Curious myself, I repeated the result on my Win7 machine and got almost
the same numbers.
class A:
def __add__(self, other): return 2
timeit.repeat('a + b', 'from __main__ import A; a=A(); b=A()')
[0.26080520927348516, 0.24120280310165754, 0.2412111032140274]
timeit.repeat('a.__add__(b)', 'from __main__ import A; a=A(); b=A()')
[0.17656398710346366, 0.15274235713354756, 0.1528444177747872]
First I looked at the byte code.
dis('a+b')
1 0 LOAD_NAME0 (a)
3 LOAD_NAME1 (b)
6 BINARY_ADD
7 RETURN_VALUE
dis('a.__add__(b)')
1 0 LOAD_NAME0 (a)
3 LOAD_ATTR1 (__add__)
6 LOAD_NAME2 (b)
9 CALL_FUNCTION1 (1 positional, 0 keyword pair)
12 RETURN_VALUE
Next the core of BINARY_ADD add code in Python/ceval.c:
if (PyUnicode_CheckExact(left)
PyUnicode_CheckExact(right)) {
sum = unicode_concatenate(left, right, f, next_instr);
/* unicode_concatenate consumed the ref to v */
}
else {
sum = PyNumber_Add(left, right);
By the language definition, PyNumber_Add must whether
issubclass(type(b), type(a)). If so, it tries b.__radd__(a). Otherwise
it tries a.__add__(b). BINARY_ADD has extra overhead before it calls
__add__. Enough to explain the differnce between .09 microsecond
difference between .25 and .16 microseconds?
Lets try some builtins..
timeit.repeat('1+1')
[0.04067762117549266, 0.019206152658126363, 0.018796680446902643]
timeit.repeat('1.0+1.0')
[0.032686457413774406, 0.023207729064779414, 0.018793606331200863]
timeit.repeat('(1.0+1j) + (1.0-1j)')
[0.037775348543391374, 0.01876409482042618, 0.018812358436889554]
timeit.repeat(''+'')
[0.04073695160855095, 0.018977745861775475, 0.018800676797354754]
timeit.repeat('a'+'b')
[0.04066932106320564, 0.01896145304840502, 0.01879268409652468]
timeit.repeat('1 .__add__(1)')
[0.16622020259652004, 0.15244908649577837, 0.15047857833215517]
timeit.repeat(''.__add__(''))
[0.17265801569533323, 0.1535966538865523, 0.15308880997304186]
For the common case of adding builtin numbers and empty strings, the
binary operation is about 8 times as fast as the dict lookup and
function call. For empty lists, the ratio is about 3
timeit.repeat('[]+[]')
[0.09728684696551682, 0.08233527043626054, 0.08230698857164498]
timeit.repeat('[].__add__([])')
[0.22780949582033827, 0.206026619382, 0.2060967092206738]
Conclusions:
1. Python-level function calls to C wrappers of C functions are as slow
as calls to Pythons functions (which I already knew to be relatively slow).
2. Taking into account the interpreters internal binary operations on
builtin Python objects, I suspect most everyone benefits from the slot
optimization.
3. The total BINARY_ADD + function call time for strings and number,
about .02 microseconds is much less that the .09 difference and cannot
account for it.
4. There might be some avoidable overhead within PyNumber_ADD that only
affects custom-class instances (but I am done for tonight;-).
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
For using python ability, what should I do???
Hello~ I'm Korean, and I register this groups just now. Thesedays, I'm studying Python 3.x version. I like Python. i read a book, python for kids a playful introduction to programming, it is very easy but very effective to me. so, I hope my python ability is higher... What should I do?? ps. In fect, I did try to Django, but it was very difficult.. Do you think I will make any program?? I want to listen your solution~ Thank you. -- https://mail.python.org/mailman/listinfo/python-list
Re: Suitable Python code to scrape specific details from web pages.
On 13/08/2014 7:28 AM, Roy Smith wrote: Second, if you're going to be parsing web pages, trying to use regexes is a losing game. You need something that knows how to parse HTML. The canonical answer is lxml (http://lxml.de/), but Beautiful Soup (http://www.crummy.com/software/BeautifulSoup/) is less intimidating to use. lxml also has a BeautifulSoup parser, so you can easily mix and match approaches: http://lxml.de/elementsoup.html -- https://mail.python.org/mailman/listinfo/python-list
Re: For using python ability, what should I do???
Jm Cho britz...@gmail.com writes: Thesedays, I'm studying Python 3.x version. I like Python. Great! Welcome to the forum. (You should avoid coming here via Google Groups, since it is a very poor application for participating in discussion forums URL:https://wiki.python.org/moin/GoogleGroupsPython. There is virtually no hope it will ever improve, so you should use e.g. URL:http://news.gmane.org/gmane.comp.python.general or any other Usenet client.) i read a book, python for kids a playful introduction to programming, it is very easy but very effective to me. Glad to know that book is helpful. so, I hope my python ability is higher... What should I do?? The Python Wiki has an index of beginner resources, please see URL:http://wiki.python.org/moin/BeginnersGuide. ps. In fect, I did try to Django, but it was very difficult.. Writing a web application is a pretty complex task, and Django provides a lot of power. You should set your expectations lower until you gain a lot more skill with the programming language. Do you think I will make any program?? Yes! See the tutorials listed at the above Beginner's Guide. You should also find *existing* projects using Python – preferably ones you use yourself already – and offer to contribute there as a means of learning. -- \ “Guaranteed to work throughout its useful life.” —packaging for | `\ clockwork toy, Hong Kong | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Topological Overlap
On 17/08/2014 4:10 AM, lavanya addepalli wrote: Actually it is a huge project and topological overlap is one part in that inputfile: 0_node_1 0_node_2 w0 1_node_1 1_node_2 w1 2_node_1 2_node_2 w2 3_node_1 3_node_2 w3 4_node_1 4_node_2 w4 5_node_1 5_node_2 w5 2 nodes in pair and w is the weight. I have to find the topological overlap in the network including the weights Have you looked at the library NetworkX? I'd start by loading your data into a weighted graph and working from there: https://networkx.github.io/documentation/latest/examples/drawing/weighted_graph.html -- https://mail.python.org/mailman/listinfo/python-list
Re: For using python ability, what should I do???
On 17Aug2014 22:04, Jm Cho britz...@gmail.com wrote: Hello~ I'm Korean, and I register this groups just now. Thesedays, I'm studying Python 3.x version. I like Python. i read a book, python for kids a playful introduction to programming, it is very easy but very effective to me. so, I hope my python ability is higher... What should I do?? Write something small that does something you want done. Initially, something trivial. If you have programmed before, rewrite something simple from another language to Python. ps. In fect, I did try to Django, but it was very difficult.. Django is a huge web framework! Write something simple that can run in a console or shell prompt or simple IDE. But it really does help to solve a (small) problem of interest to yourself. Cheers, Cameron Simpson c...@zip.com.au -- https://mail.python.org/mailman/listinfo/python-list
[issue22165] Empty response from http.server when directory listing contains invalid unicode
Senthil Kumaran added the comment:
Looks like we hit with an encoding issue, which is due to way os.fsdecode() and
os.listdir() decode the filenames.
support.TESTFN_UNDECODABLE
b'@test_99678_tmp\xe7w\xf0'
dir_list = os.listdir(self.tempdir)
dir_list
['@test_99678_tmp%E7w%F0.txt', 'test']
filename = os.fsdecode(support.TESTFN_UNDECODABLE) + '.txt'
filename
'@test_99678_tmp\udce7w\udcf0.txt'
==
FAIL: test_undecodable_filename (test.test_httpservers.SimpleHTTPServerTestCase)
--
Traceback (most recent call last):
File
/Users/buildbot/buildarea/3.4.murray-snowleopard/build/Lib/test/test_httpservers.py,
line 282, in test_undecodable_filename
.encode('utf-8', 'surrogateescape'), body)
AssertionError: b'href=%40test_62069_tmp%ED%B3%A7w%ED%B3%B0.txt' not found in
b'!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01//EN
http://www.w3.org/TR/html4/strict.dtd;\nhtml\nhead\nmeta
http-equiv=Content-Type content=text/html; charset=utf-8\ntitleDirectory
listing for tmp0asrs9ei//title\n/head\nbody\nh1Directory listing for
tmp0asrs9ei//h1\nhr\nul\nlia
href=%40test_62069_tmp%25E7w%25F0.txt@test_62069_tmp%E7w%F0.txt/a/li\nlia
href=testtest/a/li\n/ul\nhr\n/body\n/html\n'
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22165
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22165] Empty response from http.server when directory listing contains invalid unicode
Changes by Senthil Kumaran sent...@uthcode.com: -- status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22165 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22157] _ctypes on ppc64: libffi/src/powerpc/linux64.o: ABI version 1 is not compatible with ABI version 2 output
Matthias Klose added the comment: this is fixed in the 3.4 branch (post 3.4.1) and on all active branches. you should be able to use --with-system-libffi in your current environment (maybe after running: apt-get build-dep python3.4. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22157 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22165] Empty response from http.server when directory listing contains invalid unicode
Roundup Robot added the comment: New changeset a894b629bbea by Serhiy Storchaka in branch '3.4': Issue #22165: Fixed test_undecodable_filename on non-UTF-8 locales. http://hg.python.org/cpython/rev/a894b629bbea New changeset 7cdc941d5180 by Serhiy Storchaka in branch 'default': Issue #22165: Fixed test_undecodable_filename on non-UTF-8 locales. http://hg.python.org/cpython/rev/7cdc941d5180 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22165 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22165] Empty response from http.server when directory listing contains invalid unicode
Serhiy Storchaka added the comment: Oh, I missed that os.listdir() on Mac returns really strange result. Thank you Senthil. Here is a patch which try to workaround this. I'm not sure that it is enough. May be we should fix os.listdir(). Or conclude that this issue can't be fixed on Mac OS. -- components: +Macintosh nosy: +haypo, hynek, ned.deily, ronaldoussoren resolution: fixed - stage: resolved - Added file: http://bugs.python.org/file36390/test_undecodable_filename.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22165 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22193] Add _PySys_GetSizeOf()
Serhiy Storchaka added the comment: Fixed in changeset 2e417d9a2b1c. Thank you Arfrever. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22193 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22165] Empty response from http.server when directory listing contains invalid unicode
Ronald Oussoren added the comment: OSX returns a strange value in os.listdir because the HFS+ filesystem itself has unicode filenames and transforms byte strings that are assumed to contain UTF-8 into something the filesystem can handle (and seems to replace bytes that aren't valid UTF-8 into a percent-encoded value). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22165 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22213] pyvenv style virtual environments unusable in an embedded system
New submission from Graham Dumpleton:
In am embedded system, as the 'python' executable is itself not run and the
Python interpreter is initialised in process explicitly using PyInitialize(),
in order to find the location of the Python installation, an elaborate sequence
of checks is run as implemented in calculate_path() of Modules/getpath.c.
The primary mechanism is usually to search for a 'python' executable on PATH
and use that as a starting point. From that it then back tracks up the file
system from the bin directory to arrive at what would be the perceived
equivalent of PYTHONHOME. The lib/pythonX.Y directory under that for the
matching version X.Y of Python being initialised would then be used.
Problems can often occur with the way this search is done though.
For example, if someone is not using the system Python installation but has
installed a different version of Python under /usr/local. At run time, the
correct Python shared library would be getting loaded from /usr/local/lib, but
because the 'python' executable is found from /usr/bin, it uses /usr as
sys.prefix instead of /usr/local.
This can cause two distinct problems.
The first is that there is no Python installation at all under /usr
corresponding to the Python version which was embedded, with the result of it
not being able to import 'site' module and therefore failing.
The second is that there is a Python installation of the same major/minor but
potentially a different patch revision, or compiled with different binary API
flags or different Unicode character width. The Python interpreter in this case
may well be able to start up, but the mismatch in the Python modules or
extension modules and the core Python library that was actually linked can
cause odd errors or crashes to occur.
Anyway, that is the background.
For an embedded system the way this problem was overcome was for it to use
Py_SetPythonHome() to forcibly override what should be used for PYTHONHOME so
that the correct installation was found and used at runtime.
Now this would work quite happily even for Python virtual environments
constructed using 'virtualenv' allowing the embedded system to be run in that
separate virtual environment distinct from the main Python installation it was
created from.
Although this works for Python virtual environments created using 'virtualenv',
it doesn't work if the virtual environment was created using pyvenv.
One can easily illustrate the problem without even using an embedded system.
$ which python3.4
/Library/Frameworks/Python.framework/Versions/3.4/bin/python3.4
$ pyvenv-3.4 py34-pyvenv
$ py34-pyvenv/bin/python
Python 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 00:54:21)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type help, copyright, credits or license for more information.
import sys
sys.prefix
'/private/tmp/py34-pyvenv'
sys.path
['', '/Library/Frameworks/Python.framework/Versions/3.4/lib/python34.zip',
'/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4',
'/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/plat-darwin',
'/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload',
'/private/tmp/py34-pyvenv/lib/python3.4/site-packages']
$ PYTHONHOME=/tmp/py34-pyvenv python3.4
Fatal Python error: Py_Initialize: unable to load the file system codec
ImportError: No module named 'encodings'
Abort trap: 6
The basic problem is that in a pyvenv virtual environment, there is no
duplication of stuff in lib/pythonX.Y, with the only thing in there being the
site-packages directory.
When you start up the 'python' executable direct from the pyvenv virtual
environment, the startup sequence checks know this and consult the pyvenv.cfg
to extract the:
home = /Library/Frameworks/Python.framework/Versions/3.4/bin
setting and from that derive where the actual run time files are.
When PYTHONHOME or Py_SetPythonHome() is used, then the getpath.c checks
blindly believe that is the authoritative value:
* Step 2. See if the $PYTHONHOME environment variable points to the
* installed location of the Python libraries. If $PYTHONHOME is set, then
* it points to prefix and exec_prefix. $PYTHONHOME can be a single
* directory, which is used for both, or the prefix and exec_prefix
* directories separated by a colon.
/* If PYTHONHOME is set, we believe it unconditionally */
if (home) {
wchar_t *delim;
wcsncpy(prefix, home, MAXPATHLEN);
prefix[MAXPATHLEN] = L'\0';
delim = wcschr(prefix, DELIM);
if (delim)
*delim = L'\0';
joinpath(prefix, lib_python);
joinpath(prefix, LANDMARK);
return 1;
}
Because of this, the problem above occurs as the proper runtime directories for
files aren't included in sys.path. The result being that the 'encodings' module
cannot even be found.
What I believe should occur is that PYTHONHOME should not be believed
unconditionally. Instead
[issue22213] pyvenv style virtual environments unusable in an embedded system
Changes by Nick Coghlan ncogh...@gmail.com: -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22213 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22165] Empty response from http.server when directory listing contains invalid unicode
Serhiy Storchaka added the comment: Well, then the workaround should work. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22165 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22213] pyvenv style virtual environments unusable in an embedded system
Nick Coghlan added the comment: Yeah, PEP 432 (my proposal to redesign the startup sequence) could just as well be subtitled getpath.c hurts my brain :P One tricky part here is going to be figuring out how to test this - perhaps adding a new test option to _testembed and then running it both inside and outside a venv. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22213 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22213] pyvenv style virtual environments unusable in an embedded system
Nick Coghlan added the comment: Graham pointed out that setting PYTHONHOME ends up triggering the same control flow through getpath.c as calling Py_SetPythonHome, so this can be tested just with pyvenv and a suitably configured environment. It may still be a little tricky though, since we normally run the pyvenv tests in isolated mode to avoid spurious failures due to bad environment settings... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22213 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22201] python -mzipfile fails to unzip files with folders created by zip
Roundup Robot added the comment: New changeset ffa5bfe75c3a by Serhiy Storchaka in branch '2.7': Issue #22201: Command-line interface of the zipfile module now correctly http://hg.python.org/cpython/rev/ffa5bfe75c3a New changeset 7b933005c492 by Serhiy Storchaka in branch '3.4': Issue #22201: Command-line interface of the zipfile module now correctly http://hg.python.org/cpython/rev/7b933005c492 New changeset dc77ad3a17aa by Serhiy Storchaka in branch 'default': Issue #22201: Command-line interface of the zipfile module now correctly http://hg.python.org/cpython/rev/dc77ad3a17aa -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22201 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22201] python -mzipfile fails to unzip files with folders created by zip
Serhiy Storchaka added the comment: Applied first part of the patch. Thank you Ryan. For the rest please open separate issue. -- resolution: - fixed stage: patch review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22201 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22068] tkinter: avoid reference loops with Variables and Fonts
Roundup Robot added the comment: New changeset 0b79c702abda by Serhiy Storchaka in branch '2.7': Issue #22068: Avoided reference loops with Variables and Fonts in Tkinter. http://hg.python.org/cpython/rev/0b79c702abda New changeset 873002eb8087 by Serhiy Storchaka in branch '3.4': Issue #22068: Avoided reference loops with Variables and Fonts in Tkinter. http://hg.python.org/cpython/rev/873002eb8087 New changeset f44f5daff665 by Serhiy Storchaka in branch 'default': Issue #22068: Avoided reference loops with Variables and Fonts in Tkinter. http://hg.python.org/cpython/rev/f44f5daff665 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22068 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22034] posixpath.join() and bytearray
Serhiy Storchaka added the comment: Could anyone please make the review? -- assignee: - serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22034 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22193] Add _PySys_GetSizeOf()
Serhiy Storchaka added the comment: Here is alternative patch. May be it looks more clear for you. -- stage: needs patch - patch review Added file: http://bugs.python.org/file36391/_PySys_GetSizeOf_overflow_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22193 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22068] tkinter: avoid reference loops with Variables and Fonts
Changes by Serhiy Storchaka storch...@gmail.com: -- resolution: - fixed stage: patch review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22068 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22014] Improve display of OS exception - errno mapping
Jon Poler added the comment: Here's one way to accomplish this. Please see attached os_exceptions_table_V2.patch. I wasn't having much luck trying to use ReST, so I took advantage of the fact that the Doc/conf.py file is executed every time sphinx-build is run. conf.py imports and calls the main function from Doc/tools/build_table.py. This script dynamically builds a table by scraping errno values corresponding to an OS exception and inserting them in the appropriate place. Doc/library/exceptions.rst just uses a literalinclude of the new table that gets built to Lib/test/os_exception_hierarchy.txt (the same directory that holds the original exceptions hierarchy). Error catching is used so that, in the event of an error, a warning will be raised but the sphinx-build command will still succeed. -- Added file: http://bugs.python.org/file36392/os_exceptions_table_V2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22014 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22165] Empty response from http.server when directory listing contains invalid unicode
Roundup Robot added the comment: New changeset b05d4f3ee190 by Serhiy Storchaka in branch '3.4': Issue #22165: Fixed test_undecodable_filename on Mac OS. http://hg.python.org/cpython/rev/b05d4f3ee190 New changeset 58e0d2c3ead8 by Serhiy Storchaka in branch 'default': Issue #22165: Fixed test_undecodable_filename on Mac OS. http://hg.python.org/cpython/rev/58e0d2c3ead8 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22165 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22195] Make it easy to replace print() calls with logging calls
Martin Matusiak added the comment: Would it make sense for the logging module to supply something like the LoggerWriter class you wrote? With a section in the documentation that says something like have you been logging using print() this whole time? No problem, just do sys.stdout = LoggerWriter()? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22195 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22214] Tkinter: Don't stringify callbacks arguments
New submission from Serhiy Storchaka: Currently Tkinter supports two modes: * When wantobjects=1 (default), all results of Tcl/Tk commands are converted to appropriate Python objects (int, float, str, bytes, tuple) if it is possible or to Tcl_Obj for unknown Tcl types. * When wantobjects=0 (legacy mode), all results of Tcl/Tk commands are converted to strings. But arguments of a callback are always converted to str, even when wantobjects=1. This can lost information (42 is not distinguished from 42 or (42,)) and may be less efficient. Unfortunately we can't just change Tkinter to pass callback arguments as Python objects, this is backward incompatible change. Proposed patch introduces third mode wantobjects=2. It is the same as wantobjects=1, but callbacks now received . Default mode is still wantobjects=1, it can be changed in future. But in Tkinter applications (IDLE, Turtledemo, Pynche) we can use wantobjects=2 right now. The only problem left is documenting it. The wantobjects parameter is not documented at all except an entry in What's New in Python 2.3. Does anyone want to document this feature? -- components: Tkinter files: tkinter_obj_cmd.patch keywords: patch messages: 225446 nosy: gpolo, serhiy.storchaka, terry.reedy priority: normal severity: normal stage: patch review status: open title: Tkinter: Don't stringify callbacks arguments type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file36393/tkinter_obj_cmd.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22214 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22214] Tkinter: Don't stringify callbacks arguments
Changes by Serhiy Storchaka storch...@gmail.com: -- dependencies: +Run Tkinter tests with wantobjects=False ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22214 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22215] embedded NUL character exceptions
New submission from Serhiy Storchaka: Currently most functions which accepts string only without embedded NUL character, raise TypeError. Proposed patch change exception type to more consistent ValueError. It also unifies error messages. I have opened a discussion on Python-Dev. -- components: Interpreter Core files: valueerror_embedded_nul_character.diff keywords: patch messages: 225447 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: embedded NUL character exceptions type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file36394/valueerror_embedded_nul_character.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22215 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13916] disallow the surrogatepass handler for non utf-* encodings
Serhiy Storchaka added the comment: Could you please finish this issue Victor? -- assignee: - haypo stage: resolved - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13916 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22115] Add new methods to trace Tkinter variables
Serhiy Storchaka added the comment: Synchronized with the tip. -- stage: - patch review Added file: http://bugs.python.org/file36395/tkinter_trace_variable_3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22115 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22115] Add new methods to trace Tkinter variables
Changes by Serhiy Storchaka storch...@gmail.com: Removed file: http://bugs.python.org/file36179/tkinter_trace_variable_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22115 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22216] smtplip STARTTLS fails at second attampt due to unsufficiant quit()
New submission from Milan Oberkirch:
When using smtplib.SMTP to connect to a SMTP server the instance variables
esmtp_response survives a SMTP.quit() which results in the following error:
import smtplib
smtp = smtplib.SMTP('mail.oberkirch.org', 25)
smtp.starttls()
(220, b'2.0.0 Ready to start TLS')
smtp.ehlo()
(250, b'mail.oberkirch.org\nPIPELINING\nSIZE 1024\nVRFY\nETRN\nAUTH PLAIN
LOGIN\nAUTH=PLAIN LOGIN\nENHANCEDSTATUSCODES\n8BITMIME\nDSN')
smtp.quit()
(221, b'2.0.0 Bye')
smtp.connect('mail.oberkirch.org', 25)
(220, b'mail.oberkirch.org ESMTP Postfix')
smtp.starttls()
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/lib/python3.4/smtplib.py, line 672, in starttls
raise SMTPException(STARTTLS extension not supported by server.)
smtplib.SMTPException: STARTTLS extension not supported by server.
While reporting this issue I found out that starttls also does not throw away
any ehlo information as it should. Provided that fixing this would probably
break existing code (which would only work with non-standard servers like
postfix) I did not change that behaviour.
--
components: Library (Lib)
files: quit_resets_greeting.patch
keywords: patch
messages: 225450
nosy: zvyn
priority: normal
severity: normal
status: open
title: smtplip STARTTLS fails at second attampt due to unsufficiant quit()
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36396/quit_resets_greeting.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22216
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22217] Reprs for zipfile classes
New submission from Serhiy Storchaka:
Proposed patch implements __repr__() methods of three zipfile classes: ZipFile,
ZipInfo and ZipExtFile. Example:
import zipfile
zf =
zipfile.ZipFile('/usr/share/doc/texlive-base/support/makeindex/ind-src.zip')
zf
zipfile.ZipFile
filename='/usr/share/doc/texlive-base/support/makeindex/ind-src.zip' mode='r'
zf.infolist()[:2]
[ZipInfo filename='ind-src/' filemode=drwxr-xr-x external_attr=0x10, ZipInfo
filename='ind-src/fig1.tex' compress_type=deflate filemode=-r--r--r--
external_attr=0x1 file_size=1553 compress_size=518]
zf.open('ind-src/fig1.tex')
zipfile.ZipExtFile name='ind-src/fig1.tex' mode='r' compress_type=deflate
--
assignee: serhiy.storchaka
components: Library (Lib)
messages: 225451
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Reprs for zipfile classes
type: enhancement
versions: Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22217
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22217] Reprs for zipfile classes
Changes by Serhiy Storchaka storch...@gmail.com: -- keywords: +patch Added file: http://bugs.python.org/file36397/zipfile_reprs.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22217 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21549] Add the members parameter for TarFile.list()
Changes by Serhiy Storchaka storch...@gmail.com: -- assignee: - serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21549 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21549] Add the members parameter for TarFile.list()
Serhiy Storchaka added the comment: Added a test. Make the members parameter keyword-only. If there are no objections I'll commit the patch soon. -- Added file: http://bugs.python.org/file36398/tarfile_list_members_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21549 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21549] Add the members parameter for TarFile.list()
Changes by Serhiy Storchaka storch...@gmail.com: Removed file: http://bugs.python.org/file35307/tarfile_list_members.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21549 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22218] Fix more compiler warnings comparison between signed and unsigned integers
New submission from STINNER Victor: The issue #22110 enabled more compiler warnings. Attached patch fixes some of them in the Modules/ subdirectory. -- files: fix_more_warnings.patch keywords: patch messages: 225453 nosy: haypo priority: normal severity: normal status: open title: Fix more compiler warnings comparison between signed and unsigned integers versions: Python 3.5 Added file: http://bugs.python.org/file36399/fix_more_warnings.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22218 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22218] Fix more compiler warnings comparison between signed and unsigned integers
Changes by STINNER Victor victor.stin...@gmail.com: -- nosy: +neologix, serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22218 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22218] Fix more compiler warnings comparison between signed and unsigned integers
Roundup Robot added the comment: New changeset 05e8f92b58ff by Victor Stinner in branch 'default': Issue #22218: Fix comparison between signed and unsigned integers warnings in http://hg.python.org/cpython/rev/05e8f92b58ff -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22218 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22218] Fix more compiler warnings comparison between signed and unsigned integers
Serhiy Storchaka added the comment: You are very fast. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22218 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22195] Make it easy to replace print() calls with logging calls
Vinay Sajip added the comment: Would it make sense for the logging module to supply something like the LoggerWriter class you wrote? Perhaps I'm not making myself clear :-( I've posted the LoggerWriter class (not the initial version, but the later, slightly more functional one) to see if it will meet the needs that Antoine raised and Raymond concurred with. The intention is, if it meets their requirements, to indeed add the LoggerWriter class to the stdlib. If it doesn't meet the requirements, then suggestions and/or patches to improve it are welcome. However, from a smoke test, sys.stdout = LoggerWriter() doesn't seem to work as expected, but I can't see why at the moment (and currently I'm not able to give it my undivided attention). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22195 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22219] python -mzipfile fails to add empty folders to created zip
New submission from Antony Lee:
Compare
$ mkdir foo; zip -q foo{,}; unzip -l foo.zip
Archive: foo.zip
Length DateTimeName
- -- -
0 2014-08-17 10:49 foo/
- ---
0 1 file
and
$ mkdir foo; python -mzipfile -c foo{.zip,}; unzip -l foo.zip
Archive: foo.zip
warning [foo.zip]: zipfile is empty
A patch was posted by Ryan Wilson in related issue #22201.
--
components: Library (Lib)
messages: 225457
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: python -mzipfile fails to add empty folders to created zip
versions: Python 3.4, Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22219
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22212] zipfile.py fails if zlib.so module fails to build.
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti stage: - needs patch type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22212 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22219] python -mzipfile fails to add empty folders to created zip
Changes by Serhiy Storchaka storch...@gmail.com: -- assignee: - serhiy.storchaka nosy: +serhiy.storchaka stage: - needs patch type: - behavior versions: +Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22219 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22220] Ttk extensions test failure
New submission from Serhiy Storchaka: Strange test failure on one of Windows buildbots: http://buildbot.python.org/all/builders/x86%20Windows%20Server%202003%20%5BSB%5D%203.x/builds/2393/steps/test/logs/stdio == ERROR: test_horizontal_range (tkinter.test.test_ttk.test_extensions.LabeledScaleTest) -- Traceback (most recent call last): File D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\tkinter\test\test_ttk\test_extensions.py, line 113, in test_horizontal_range lscale.pack() File D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\tkinter\__init__.py, line 1952, in pack_configure + self._options(cnf, kw)) _tkinter.TclError: cannot use geometry manager pack inside . which already has slaves managed by grid == ERROR: test_resize (tkinter.test.test_ttk.test_extensions.LabeledScaleTest) -- Traceback (most recent call last): File D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\tkinter\test\test_ttk\test_extensions.py, line 175, in test_resize x.pack(expand=True, fill='both') File D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\tkinter\__init__.py, line 1952, in pack_configure + self._options(cnf, kw)) _tkinter.TclError: cannot use geometry manager pack inside . which already has slaves managed by grid == ERROR: test_variable_change (tkinter.test.test_ttk.test_extensions.LabeledScaleTest) -- Traceback (most recent call last): File D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\tkinter\test\test_ttk\test_extensions.py, line 143, in test_variable_change x.pack() File D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\tkinter\__init__.py, line 1952, in pack_configure + self._options(cnf, kw)) _tkinter.TclError: cannot use geometry manager pack inside . which already has slaves managed by grid == ERROR: test_menu (tkinter.test.test_ttk.test_extensions.OptionMenuTest) -- Traceback (most recent call last): File D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\tkinter\test\test_ttk\test_extensions.py, line 256, in test_menu optmenu.pack() File D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\tkinter\__init__.py, line 1952, in pack_configure + self._options(cnf, kw)) _tkinter.TclError: cannot use geometry manager pack inside . which already has slaves managed by grid -- May be it relates to my last Tkinter changes or may be it is just sporadic failure. -- assignee: serhiy.storchaka components: Tkinter messages: 225458 nosy: serhiy.storchaka priority: normal severity: normal stage: test needed status: open title: Ttk extensions test failure type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue0 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22219] python -mzipfile fails to add empty folders to created zip
Serhiy Storchaka added the comment: Directory entry should be added not only when directory is empty. See also issue20912. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22219 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22218] Fix more compiler warnings comparison between signed and unsigned integers
Roundup Robot added the comment: New changeset ca5eef14c1ab by Victor Stinner in branch 'default': Issue #22218: Fix comparison between signed and unsigned integers warnings in http://hg.python.org/cpython/rev/ca5eef14c1ab -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22218 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22218] Fix more compiler warnings comparison between signed and unsigned integers
Roundup Robot added the comment: New changeset 2f2c1816d0c7 by Victor Stinner in branch 'default': Issue #22218: Fix comparison between signed and unsigned integers warning in http://hg.python.org/cpython/rev/2f2c1816d0c7 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22218 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21520] Erroneous zipfile test failure if the string 'bad' appears in pwd
Serhiy Storchaka added the comment: The line is too long. It would be better to extract a filter as regular function. Otherwise LGTM. -- nosy: +serhiy.storchaka stage: needs patch - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21520 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22218] Fix more compiler warnings comparison between signed and unsigned integers
STINNER Victor added the comment: You are very fast. Oh sorry. In fact, I didn't expect a review. I just created an issue to put an issue number in the commit changelog and give a little bit more context to my changes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22218 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2527] Pass a namespace to timeit
Changes by Ben Roberts bjr.robe...@gmail.com: -- nosy: +roippi ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2527 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22221] ast.literal_eval confused by coding declarations
New submission from Jorgen Schäfer: The ast module seems to get confused for certain strings which contain coding declarations. import ast s = u'\\\n# -*- coding: utf-8 -*-\n' print s \ # -*- coding: utf-8 -*- ast.literal_eval(s) Traceback (most recent call last): File stdin, line 1, in module File /home/forcer/Programs/Python/python2.7/lib/python2.7/ast.py, line 49, in literal_eval node_or_string = parse(node_or_string, mode='eval') File /home/forcer/Programs/Python/python2.7/lib/python2.7/ast.py, line 37, in parse return compile(source, filename, mode, PyCF_ONLY_AST) File unknown, line 0 SyntaxError: encoding declaration in Unicode string -- components: Library (Lib) messages: 225464 nosy: jorgenschaefer priority: normal severity: normal status: open title: ast.literal_eval confused by coding declarations versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22222] dtoa.c: remove custom memory allocator
New submission from STINNER Victor: dtoa.c has an optimized memory allocator for performances: it uses a short pool of 2304 doubles (18 KB) to avoid calling malloc/free. Comment in dtoa.c: /* Memory management: memory is allocated from, and returned to, Kmax+1 pools of memory, where pool k (0 = k = Kmax) is for Bigints b with b-maxwds == 1 k. These pools are maintained as linked lists, with freelist[k] pointing to the head of the list for pool k. On allocation, if there's no free slot in the appropriate pool, MALLOC is called to get more memory. This memory is not returned to the system until Python quits. There's also a private memory pool that's allocated from in preference to using MALLOC. For Bigints with more than (1 Kmax) digits (which implies at least 1233 decimal digits), memory is directly allocated using MALLOC, and freed using FREE. XXX: it would be easy to bypass this memory-management system and translate each call to Balloc into a call to PyMem_Malloc, and each Bfree to PyMem_Free. Investigate whether this has any significant performance on impact. */ Python already has such memory pool: PyObject_Malloc(). I propose to reuse it. It avoids wasting memory until Python quits just to optimize dtoa.c. dtoa.c memory pool is only used for allocations smaller than 68 bytes (on 64 bits system, Kmax=7). PyObject_Malloc() is optimized for allocations smaller than 513 bytes, so it's ok. See also the issue #7632. -- files: dtoa_remove_custom_alloc.patch keywords: patch messages: 225465 nosy: haypo, mark.dickinson, skrah priority: normal severity: normal status: open title: dtoa.c: remove custom memory allocator versions: Python 3.5 Added file: http://bugs.python.org/file36400/dtoa_remove_custom_alloc.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22153] There is no standard TestCase.runTest implementation
evilzero added the comment: Updated documentation following suggestion. -- keywords: +patch nosy: +evilzero Added file: http://bugs.python.org/file36401/myworkdoc.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22153 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22153] There is no standard TestCase.runTest implementation
Changes by evilzero losvampi...@yahoo.com: -- type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22153 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22221] ast.literal_eval confused by coding declarations
Changes by David Halter davidhalte...@gmail.com: -- nosy: +davidhalter ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22206] PyThread_create_key(): fix comparison between signed and unsigned numbers in Python/thread_pthread.h
Roundup Robot added the comment: New changeset 1b898b5d5ffe by Victor Stinner in branch 'default': Issue #22206: Using pthread, PyThread_create_key() now sets errno to ENOMEM and http://hg.python.org/cpython/rev/1b898b5d5ffe -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22206 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22206] PyThread_create_key(): fix comparison between signed and unsigned numbers in Python/thread_pthread.h
STINNER Victor added the comment: I fixed the issue in Python 3.5, I close the issue. Even if Python 2.7 and 3.4 are also affected, I prefer to not modify them to not take the risk of introducing a regression for a corner case. -- resolution: - fixed status: open - closed versions: -Python 2.7, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22206 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22221] ast.literal_eval confused by coding declarations
Serhiy Storchaka added the comment: eval() is affected too. 3.x isn't affected. -- assignee: - serhiy.storchaka components: +Interpreter Core -Library (Lib) nosy: +serhiy.storchaka stage: - needs patch type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22222] dtoa.c: remove custom memory allocator
Serhiy Storchaka added the comment: This is very dangerous change. Could you please compare results of Python benchmarks with and without the patch? -- nosy: +pitrou, serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10583] Encoding issue with chm help in 2.7.1
Mark Lawrence added the comment: Is there anything to be done here as Sphinx is a third party tool and the root cause is already fixed? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10583 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6759] zipfile.ZipExtFile.read() is missing universal newline support
Serhiy Storchaka added the comment: Mode 'U' is deprecated now (issue15204). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6759 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22222] dtoa.c: remove custom memory allocator
Stefan Krah added the comment: A modified version of telco.py (using floats instead of decimals) runs about 5-6% slower with the change here. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22222] dtoa.c: remove custom memory allocator
Changes by Eric V. Smith e...@trueblade.com: -- nosy: +eric.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22195] Make it easy to replace print() calls with logging calls
Antoine Pitrou added the comment:
However, from a smoke test, sys.stdout = LoggerWriter() doesn't seem to work
as expected
I wasn't thinking about replacing sys.stdout (which I think is in general a bad
pattern, except for daemonized processes), rather being able to 1) either
replace the print() calls with logging calls with a similar API or 2) add a
file= argument to print calls.
(the 1) solution could look like print =
logging.getLogger('foo').debug_printer())
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22195
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22207] Test for integer overflow on Py_ssize_t: explicitly cast to size_t
Roundup Robot added the comment: New changeset 97c70528b604 by Victor Stinner in branch 'default': Issue #22207: Fix comparison between signed and unsigned integers warning in http://hg.python.org/cpython/rev/97c70528b604 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22207 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22207] Test for integer overflow on Py_ssize_t: explicitly cast to size_t
STINNER Victor added the comment: I commited the first part. The remaining part is a long patch for unicodeobject.c. -- Added file: http://bugs.python.org/file36402/unicode.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22207 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
