SQLObject 2.0
Hello! I'm pleased to announce version 2.0.0, the first stable release of branch 2.0 of SQLObject. What's new in SQLObject === Features Interface * DateTimeCol and TimeCol can read and write values with microseconds. WARNING: microseconds are supported by MariaDB since version 5.3.0 and by MySQL since version 5.6.4, and even these versions require special handling: columns to store microseconds have to be declared with precision 6: TIME(6), DATETIME(6), TIMESTAMP(6). SQLObject does the right thing when creating a new database but existing databases have to be changed: run something like ``ALTER TABLE name MODIFY COLUMN col TIME(6)`` for every column that you want to store microseconds. WARNING: backward compatibility problem! Date/Time columns created with microseconds cannot be read back from SQLite databases (and perhaps other backends) with versions of SQLObject older than 1.7. Minor features -- * PostgresConnection, when used with fromDatabase=True, sets alternateID for unique columns. * Extend sdist: include everything (even generated html) into source distribution. * Extend setup.py: include docs and tests into the egg. Development --- * Development was switched from Subversion to git. Documentation - * Old news were restored back to version 0.2.1. * News.txt was split into 5 small files. Contributors for this release are Andrew Trusty and Jared Jennings. For a more complete list, please see the news: http://sqlobject.org/News.html What is SQLObject = SQLObject is an object-relational mapper. Your database tables are described as classes, and rows are instances of those classes. SQLObject is meant to be easy to use and quick to get started with. SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite, Firebird, Sybase, MSSQL and MaxDB (also known as SAPDB). Python 2.6 or 2.7 is required. Where is SQLObject == Site: http://sqlobject.org Development: http://sqlobject.org/devel/ Mailing list: https://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss Archives: http://news.gmane.org/gmane.comp.python.sqlobject Download: https://pypi.python.org/pypi/SQLObject/2.0.0 News and changes: http://sqlobject.org/News.html Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. -- https://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
what is wrong with d.clear()?
Hi,
where am i going wrong ?
$ python3
Python 3.2.5 (default, Oct 2 2013, 22:58:11)
[GCC 4.8.1] on cygwin
Type help, copyright, credits or license for more information.
d = {}
import sys
d = sys.modules
type(d)
class 'dict'
dir(d)
['__class__', '__contains__', '__delattr__', '__delitem__', '__doc__',
'__eq__', '__format__', '__ge__', '__getattribute__', '__getitem__',
'__gt__', '__hash__', '__init__', '__iter__', '__le__', '__len__',
'__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__',
'__setattr__', '__setitem__', '__sizeof__', '__str__', '__subclasshook__',
'clear', 'copy', 'fromkeys', 'get', 'items', 'keys', 'pop', 'popitem',
'setdefault', 'update', 'values']
d.clear()
Traceback (most recent call last):
File stdin, line 1, in module
d
Traceback (most recent call last):
File stdin, line 1, in module
quit()
Traceback (most recent call last):
File stdin, line 1, in module
Thanks in advance.
Best regards,
Shawool
--
https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
Chris Angelico ros...@gmail.com: Level 0: Why implement your own crypto?!? Licensing concerns come to mind. For example, the reference implementations of MD5 [RFC1321] and SHA1 [RFC3174] are not in the public domain. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: what is wrong with d.clear()?
On 12/21/2014 2:28 AM, shawool wrote:
where am i going wrong ?
You clear sys.modules, which apparently CPython uses in its normal function.
Python 3.2.5 (default, Oct 2 2013, 22:58:11)
d = {}
import sys
d = sys.modules
type(d)
class 'dict'
dir(d)
['__class__', '__contains__', '__delattr__', '__delitem__', '__doc__',
'__eq__', '__format__', '__ge__', '__getattribute__', '__getitem__',
'__gt__', '__hash__', '__init__', '__iter__', '__le__', '__len__',
'__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__',
'__repr__', '__setattr__', '__setitem__', '__sizeof__', '__str__',
'__subclasshook__', 'clear', 'copy', 'fromkeys', 'get', 'items', 'keys',
'pop', 'popitem', 'setdefault', 'update', 'values']
dir(d) is the contents of d.__dict__, not d itself, so the above is not
what you clear. Just type d to see what is cleared.
d.clear()
Traceback (most recent call last):dir(
File stdin, line 1, in module
There is no code line because the exception in in C code. 3.4.2 gives
more info: RuntimeError: lost builtins module. Do upgrade if you can.
In Idle, this executes 'ok', without an exception, because it clears
sys.modules in the user process, not the Idle process.
d
Traceback (most recent call last):
File stdin, line 1, in module
However, this throws the user process into a loop, literally.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
On Mon, Dec 22, 2014 at 7:52 PM, Marko Rauhamaa ma...@pacujo.net wrote: Chris Angelico ros...@gmail.com: Level 0: Why implement your own crypto?!? Licensing concerns come to mind. For example, the reference implementations of MD5 [RFC1321] and SHA1 [RFC3174] are not in the public domain. Which would you prefer? Something with licensing restrictions, or something that's either outright buggy, completely insecure due to something you didn't notice, or maybe has an unnoticed side-channel attack that leaks your keys? While these can happen with well-known libraries like libssl, they also get patched; when Heartbleed went public, updates to the affected versions were available pretty quickly, but if you had your own implementation, someone might be leaking your keys without your knowledge and you have to fix it yourself... if you ever notice. But we're somewhat off topic now... ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
Steve Hayes wrote:
Yes, my initial reaction was that's awesome.
And my second thought was that it was scary.
I ran it. It worked, and printed Hello world. I was awed.
But what if I had run it and it reformatted my hard disk?
How would I have known that it would or wouldn't do that?
That's why I didn't run it myself :-)
Seriously. I read the blog post, it seemed legitimate, I could follow the
explanation for how it worked well enough to be convinced it would work,
but I didn't try running it myself.
If I had, I would have made sure I was running as an unprivileged user, not
the superuser/Administrator account. Actually, since I care more about my
personal files than the operating system, I'd prefer to *not* use my normal
account. This being Linux, I can run suspicious code as the nobody user:
[steve@ando ~]$ sudo -u nobody python -c print 'Hello World'
Hello World
Running as nobody limits the harm a rogue script might do:
[steve@ando ~]$ sudo -u nobody python -c import os;
os.listdir('/home/steve')
Traceback (most recent call last):
File string, line 1, in ?
OSError: [Errno 13] Permission denied: '/home/steve'
Ultimately, I'm trusting the security of my operating system.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: List Comprehensions
Ganesh Pal wrote: Hi , (a) I was trying to reduce the below piece of code using List comprehension ? Any suggestion please let me know for opt in options: opt['result'] = Queue.Queue() tmp_thread = pause.Thread(opt) threads.append(tmp_thread) tmp_thread.start() Why do you think a list comprehension is appropriate here? A list comprehension is appropriate when you are building a list of results, with no side-effects. Something like this: results = [] # We want these results. for item in items: tmp = function(item) # Should have NO side-effects. results.append(tmp) # We only care about the result of each call. can be re-written as a list comp: results = [function(item) for item in items] If the called function has side-effects, a list comp is not a good solution. If you don't care about the results, a list comp is not a good solution. List comps were not invented as a way to squash arbitrarily complicated for-loops into a single line. This is Python, not Perl. (b) * Is there anything that I need to consider while using list comprehension with threads ?* That depends on what you mean by using list comprehension with threads. If you mean use a list comprehension inside a thread, then no, you don't need to be concerned. So long as your functions are pure functions with no side-effects, running a list comp inside one thread cannot affect any other thread. If you mean, running threads inside the list comprehension, then absolutely you need to be concerned. You need to take the exact same precautions to run threaded code safely, regardless of whether the threads are running in a for-loop or a list comp. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info: Steve Hayes wrote: But what if I had run it and it reformatted my hard disk? How would I have known that it would or wouldn't do that? That's why I didn't run it myself :-) Well, I admit having run yum install python3 as root. Ultimately, I'm trusting the security of my operating system. Ultimately, I'm trusting my luck. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: List Comprehensions
On Mon, Dec 22, 2014 at 8:21 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: If the called function has side-effects, a list comp is not a good solution. Hmm. I'm not so sure about that. Side effects are fine in a list comp, as long as you're making use of the return values. For instance, if you have a function that inserts a record to a database and returns the new ID, you could reasonably use a list comp to save a bunch of records and get a list of IDs for subsequent use. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: what is wrong with d.clear()?
On 12/21/14 2:28 AM, shawool wrote:
Hi,
where am i going wrong ?
$ python3
Python 3.2.5 (default, Oct 2 2013, 22:58:11)
[GCC 4.8.1] on cygwin
Type help, copyright, credits or license for more information.
d = {}
import sys
d = sys.modules
This does not make a copy of sys.modules. This make d refer to the
actual sys.modules dictionary.
type(d)
class 'dict'
dir(d)
['__class__', '__contains__', '__delattr__', '__delitem__', '__doc__',
'__eq__', '__format__', '__ge__', '__getattribute__', '__getitem__',
'__gt__', '__hash__', '__init__', '__iter__', '__le__', '__len__',
'__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__',
'__repr__', '__setattr__', '__setitem__', '__sizeof__', '__str__',
'__subclasshook__', 'clear', 'copy', 'fromkeys', 'get', 'items', 'keys',
'pop', 'popitem', 'setdefault', 'update', 'values']
d.clear()
This cleared the contents of d, which is also sys.modules, so you have
clobbered sys.modules. This will make many things stop working in Python.
Traceback (most recent call last):
File stdin, line 1, in module
d
Traceback (most recent call last):
File stdin, line 1, in module
quit()
Traceback (most recent call last):
File stdin, line 1, in module
Like all of these things.
--
Ned Batchelder, http://nedbatchelder.com
--
https://mail.python.org/mailman/listinfo/python-list
Re: List Comprehensions
In article mailman.17109.1419228400.18130.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: On Mon, Dec 22, 2014 at 4:42 PM, Ganesh Pal ganesh1...@gmail.com wrote: (a) I was trying to reduce the below piece of code using List comprehension ? Any suggestion please let me know for opt in options: opt['result'] = Queue.Queue() tmp_thread = pause.Thread(opt) threads.append(tmp_thread) tmp_thread.start() (b)Is there anything that I need to consider while using list comprehension with threads ? Your code is doing several things at once, so it's probably not worth trying to turn it into a comprehension. I don't think it needs to be shortened, anyway; looks fine to me. I pretty much agree with Chris. If I were to refactor this, however, I would probably pull the body of the loop out into a function, then it might make sense to do the accumulation of threads in a comprehension: def init_thread(opt): opt['result'] = Queue.Queue() thread = pause.Thread(opt) thread.start() return thread threads = [init_thread(opt) for opt in options] But, really, I think the way you had it originally was cleaner. -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
In article 0udf9a1m3n02rt06a5ib58mvifm7sde...@4ax.com, Steve Hayes hayes...@telkomsa.net wrote: On Mon, 22 Dec 2014 09:51:02 +1100, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Tony the Tiger wrote: On Sat, 20 Dec 2014 23:57:08 +1100, Steven D'Aprano wrote: I am in total awe. I'm not. It has no real value. Write your code like that and you'll soon be looking for a new job. Awww, did da widdle puddy tat get up on the wrong side of the bed this morning? :-) Obviously you don't write obfuscated code like this for production use, except in such cases where you deliberately want to write obfuscated code for production use. Yes, my initial reaction was that's awesome. And my second thought was that it was scary. I ran it. It worked, and printed Hello world. I was awed. But what if I had run it and it reformatted my hard disk? How would I have known that it would or wouldn't do that? How would you know any code you download from the net won't reformat your disk? If I wanted to write something evil, I wouldn't write it to look obfuscated. I'd write it to look like it did something useful. -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
In article 5497e1d5$0$12978$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Steve Hayes wrote: Yes, my initial reaction was that's awesome. And my second thought was that it was scary. I ran it. It worked, and printed Hello world. I was awed. But what if I had run it and it reformatted my hard disk? How would I have known that it would or wouldn't do that? That's why I didn't run it myself :-) Seriously. I read the blog post, it seemed legitimate, I could follow the explanation for how it worked well enough to be convinced it would work, but I didn't try running it myself. If I had, I would have made sure I was running as an unprivileged user, not the superuser/Administrator account. Actually, since I care more about my personal files than the operating system, I'd prefer to *not* use my normal account. This being Linux, I can run suspicious code as the nobody user: If I really didn't trust something, I'd go to AWS and spin up one of their free-tier micro instances and run it there :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: List Comprehensions
On Tue, Dec 23, 2014 at 12:07 AM, Roy Smith r...@panix.com wrote: def init_thread(opt): opt['result'] = Queue.Queue() thread = pause.Thread(opt) thread.start() return thread threads = [init_thread(opt) for opt in options] If this is, indeed, just initializing the threads, then this might make sense. Or alternatively, if you could subclass threading.Thread and do all the work in __init__, then you could simply construct them all: class whatever(thread.Thread): def __init__(self, opt): self.queue = Queue.Queue() self.opt = opt super().__init__() self.start() threads = [whatever(opt) for opt in options] Just as long as you can come up with a sane name for the class, or the initializer function, that makes sense without the list comp. Incidentally, this is part of what I was saying about side effects being okay in a list comp; either Roy's or my examples here would be a list comp that has the side effect of starting a bunch of threads, and I don't see it as being at all problematic. Just don't use a list comp for _just_ the side effects. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
On Tue, Dec 23, 2014 at 12:15 AM, Roy Smith r...@panix.com wrote: If I really didn't trust something, I'd go to AWS and spin up one of their free-tier micro instances and run it there :-) How do you know it won't create console output that stroboscopically infects you with a virus through your eyes? Because that's *totally* what would be done in the town of Eureka. (I miss that show. Their technobabble was so mindbogglingly bad it became rather funny.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
Roy Smith r...@panix.com: If I really didn't trust something, I'd go to AWS and spin up one of their free-tier micro instances and run it there :-) Speaking of trust and AWS, Amazon admins—and by extension, the NSA—have full access to the virtual machines. That needs to be taken into account when running serious services on their facilities. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
In article 87egrrrf2i@elektro.pacujo.net, Marko Rauhamaa ma...@pacujo.net wrote: Roy Smith r...@panix.com: If I really didn't trust something, I'd go to AWS and spin up one of their free-tier micro instances and run it there :-) Speaking of trust and AWS, Amazon adminsâand by extension, the NSAâhave full access to the virtual machines. That needs to be taken into account when running serious services on their facilities. Marko Nobody who is really serious about security runs their stuff in any kind of shared infrastructure. -- https://mail.python.org/mailman/listinfo/python-list
Re: List Comprehensions
On Monday, December 22, 2014 6:52:12 PM UTC+5:30, Chris Angelico wrote: On Tue, Dec 23, 2014 at 12:07 AM, Roy Smith wrote: def init_thread(opt): opt['result'] = Queue.Queue() thread = pause.Thread(opt) thread.start() return thread threads = [init_thread(opt) for opt in options] If this is, indeed, just initializing the threads, then this might make sense. Or alternatively, if you could subclass threading.Thread and do all the work in __init__, then you could simply construct them all: class whatever(thread.Thread): def __init__(self, opt): self.queue = Queue.Queue() self.opt = opt super().__init__() self.start() threads = [whatever(opt) for opt in options] Just as long as you can come up with a sane name for the class, or the initializer function, that makes sense without the list comp. Incidentally, this is part of what I was saying about side effects being okay in a list comp; either Roy's or my examples here would be a list comp that has the side effect of starting a bunch of threads, and I don't see it as being at all problematic. I see it as Ewww!!! If you consider side-effecting comprehensions as kosher, then a next conclusion is naturally going to be that multiple generator comprehensions are confusing and therefore not kosher -- a very unfortunate conclusion IMHO. Steven's results = [function(item) for item in items] If the called function has side-effects, a list comp is not a good solution. If you don't care about the results, a list comp is not a good solution. should be standard fare for beginners beginners befuddled by comprehensions To the OP: Comprehensions are not for-statements any more than conditional expressions are if-statements. In both cases you want the first for the value, the second for the effect. Its another matter that you can usually refactor one into the other. The larger context of your code is not visible so cant elaborate more on that now... -- https://mail.python.org/mailman/listinfo/python-list
Re: List Comprehensions
On Tue, Dec 23, 2014 at 1:58 AM, Rustom Mody rustompm...@gmail.com wrote: If you consider side-effecting comprehensions as kosher, then a next conclusion is naturally going to be that multiple generator comprehensions are confusing and therefore not kosher -- a very unfortunate conclusion IMHO. Why does that follow? What has that to do with side effects? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: List Comprehensions
On Mon, Dec 22, 2014 at 2:21 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: (b) * Is there anything that I need to consider while using list comprehension with threads ?* That depends on what you mean by using list comprehension with threads. If you mean use a list comprehension inside a thread, then no, you don't need to be concerned. So long as your functions are pure functions with no side-effects, running a list comp inside one thread cannot affect any other thread. It could, however, be itself affected by other threads modifying the same data if one isn't careful. -- https://mail.python.org/mailman/listinfo/python-list
Re: List Comprehensions
Chris Angelico wrote: On Mon, Dec 22, 2014 at 8:21 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: If the called function has side-effects, a list comp is not a good solution. Hmm. I'm not so sure about that. Side effects are fine in a list comp, as long as you're making use of the return values. For instance, if you have a function that inserts a record to a database and returns the new ID, you could reasonably use a list comp to save a bunch of records and get a list of IDs for subsequent use. I hear what you are saying, but a list comprehension is a functional idiom. To mix functional and procedural idioms in the one expression is rather icky. Better to use one or the other but not both simultaneously. I'll accept that this is a weak recommendation though. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
Roy Smith wrote: If I wanted to write something evil, I wouldn't write it to look obfuscated. I'd write it to look like it did something useful. That's an order of magnitude harder than merely obfuscating code. If you wanted to write something evil, better to just rely on the fact that most people won't read the source code at all. Don't try this at home! # download_naked_pictures_of_jennifer_lawrence.py import os os.system(rm ――rf /) -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
Steven D'Aprano writes: Don't try this at home! # download_naked_pictures_of_jennifer_lawrence.py import os os.system(rm ――rf /) Not sure what that character is (those characters are) but it's not (they aren't) the hyphen that rm expects in its options, so: os.system(rm ――rf /) rm: cannot remove `――rf': No such file or directory rm: cannot remove `/': Is a directory 256 :) -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
On Mon, Dec 22, 2014 at 9:22 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Don't try this at home! # download_naked_pictures_of_jennifer_lawrence.py import os os.system(rm ――rf /) And because Steven *knows* some fool will try this at home, he cripples the rm command. Now where's the fun in that? :-) Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: very weird pandas behavior
On Saturday, December 20, 2014 10:46:40 AM UTC-5, ryguy7272 wrote: I downloaded pandas and put it in my python directory, then, at the C-prompt, I ran this: pip install pandas It looks like everything downloaded and installed fine. Great. Now, in Python Shell, I enter this: import pandas as pd I get this error. Traceback (most recent call last): File pyshell#19, line 1, in module import pandas as pd ImportError: No module named pandas Any idea what I'm doing wrong? Thanks Rustom. That is insightful advice, indeed. I will cherish your wisdom. To everyone else, I'm going back to VBA, VB, C#, Java, SQL, SSIS, R, Matlab, simply because all of those work perfectly fine. I have countless ways to do everything in the world. For me, Python was just another way to do, what I already do now. I don't have time to screw around with all kind of nonsense that doesn't do anything, other than tell me 1+1=2. That pretty much the only thing that works in Python. To do anything more complex, seems impossible. Rather than make the impossible become possible, I'd rather focus on things that help me do stuff (like process 100,000 man-hours of work in less than 1 hour). Learning Python was both fun frustrating. If you need to waste time, work with Python. If you need to do real work, use any on the following: VBA, VB, C#, Java, SQL, R, Matlab. I just uninstalled Python and deleted 15 Python books that I found online. AH! I feel great That's all. -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
On Mon, Dec 22, 2014 at 4:36 PM, Jussi Piitulainen jpiit...@ling.helsinki.fi wrote: Steven D'Aprano writes: Don't try this at home! # download_naked_pictures_of_jennifer_lawrence.py import os os.system(rm ――rf /) Not sure what that character is (those characters are) but it's not (they aren't) the hyphen that rm expects in its options, so: os.system(rm ――rf /) rm: cannot remove `――rf': No such file or directory rm: cannot remove `/': Is a directory 256 Let‘s ask Python: (polyglot 2.6+/3.3+ code!) from __future__ import print_function import unicodedata command = urm ――rf / for i in command: print(hex(ord(i)), unicodedata.name(i)) 0x72 LATIN SMALL LETTER R 0x6d LATIN SMALL LETTER M 0x20 SPACE 0x2015 HORIZONTAL BAR 0x2015 HORIZONTAL BAR 0x72 LATIN SMALL LETTER R 0x66 LATIN SMALL LETTER F 0x20 SPACE 0x2f SOLIDUS There’s your answer: it’s U+2015 HORIZONTAL BAR, twice. And `rm` wants U+002D HYPHEN-MINUS instead. Moreover, it wants only one HYPHEN-MINUS and not two: Linux: $ rm --rf / rm: unrecognized option '--rf' Try 'rm --help' for more information. BSD: $ rm --rf / rm: illegal option -- - usage: rm [-f | -i] [-dIPRrvWx] file ... unlink file That’s two-step “protection”. (This e-mail brought to you by Unicode.) -- Chris Warrick https://chriswarrick.com/ PGP: 5EAAEA16 -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
On 2014-12-21, Tony the Tiger tony@tiger.invalid wrote: On Sat, 20 Dec 2014 23:57:08 +1100, Steven D'Aprano wrote: I am in total awe. I'm not. It has no real value. Write your code like that and you'll soon be looking for a new job. I think you'll find that people who know enough to write code like that only do it for entertainment purposes. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
On 2014-12-21, Roy Smith r...@panix.com wrote: In article 54974ed7$0$12986$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Obviously you don't write obfuscated code like this for production use, except in such cases where you deliberately want to write obfuscated code for production use. Heh. I once worked on a C++ project that included its own crypo code (i.e. custom implementations of things like AES and SHA-1). Damn. Should I ever start to do something like that (for a real product), I hereby officially request that somebody please try to slap some sense into me. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
On 2014-12-22, Steve Hayes hayes...@telkomsa.net wrote: On Mon, 22 Dec 2014 09:51:02 +1100, Steven D'Apranosteve+comp.lang.pyt...@pearwood.info wrote: Obviously you don't write obfuscated code like this for production use, except in such cases where you deliberately want to write obfuscated code for production use. Yes, my initial reaction was that's awesome. And my second thought was that it was scary. I ran it. It worked, and printed Hello world. I was awed. But what if I had run it and it reformatted my hard disk? How would I have known that it would or wouldn't do that? Well not running it as root would be start -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: List Comprehensions
On 22/12/2014 05:42, Ganesh Pal wrote: Hi , (a) I was trying to reduce the below piece of code using List comprehension ? Any suggestion please let me know for opt in options: opt['result'] = Queue.Queue() tmp_thread = pause.Thread(opt) threads.append(tmp_thread) tmp_thread.start() If it ain't broke don't fix it :) -- 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: very weird pandas behavior
On 22/12/2014 15:55, ryguy7272 wrote: On Saturday, December 20, 2014 10:46:40 AM UTC-5, ryguy7272 wrote: I downloaded pandas and put it in my python directory, then, at the C-prompt, I ran this: pip install pandas It looks like everything downloaded and installed fine. Great. Now, in Python Shell, I enter this: import pandas as pd I get this error. Traceback (most recent call last): File pyshell#19, line 1, in module import pandas as pd ImportError: No module named pandas Any idea what I'm doing wrong? Thanks Rustom. That is insightful advice, indeed. I will cherish your wisdom. To everyone else, I'm going back to VBA, VB, C#, Java, SQL, SSIS, R, Matlab, simply because all of those work perfectly fine. I have countless ways to do everything in the world. For me, Python was just another way to do, what I already do now. I don't have time to screw around with all kind of nonsense that doesn't do anything, other than tell me 1+1=2. That pretty much the only thing that works in Python. To do anything more complex, seems impossible. Rather than make the impossible become possible, I'd rather focus on things that help me do stuff (like process 100,000 man-hours of work in less than 1 hour). Learning Python was both fun frustrating. If you need to waste time, work with Python. If you need to do real work, use any on the following: VBA, VB, C#, Java, SQL, R, Matlab. I just uninstalled Python and deleted 15 Python books that I found online. AH! I feel great That's all. https://www.python.org/about/success/ Python is part of the winning formula for productivity, software quality, and maintainability at many companies and institutions around the world. Here are 41 real-life Python success stories, classified by application domain. So it looks as if this is yet another case of a bad workman always blames his tools, we seem to have had a lot of them this year. -- 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: very weird pandas behavior
On 12/22/2014 10:55 AM, ryguy7272 wrote: I just uninstalled Python and deleted 15 Python books that I found online. AH! I feel great That's the way i felt when I uninstalled Windows. It's better not to not have something installed that you won't run. Likewise, it's best to delete books that you haven't actually studied. If you had downloaded just one book, and actually used it the way it was designed, and on the corresponding version of Python, the outcome might have been very different. (I lied. I kept Windows, in a Virtualbox, so I can resurrect it on demand) -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
Skip Montanaro wrote: On Mon, Dec 22, 2014 at 9:22 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Don't try this at home! # download_naked_pictures_of_jennifer_lawrence.py import os os.system(rm ――rf /) And because Steven *knows* some fool will try this at home, he cripples the rm command. Now where's the fun in that? :-) Ah, I'm just a big softie :-) -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: List Comprehensions
On Tue, Dec 23, 2014 at 2:18 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Chris Angelico wrote: On Mon, Dec 22, 2014 at 8:21 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: If the called function has side-effects, a list comp is not a good solution. Hmm. I'm not so sure about that. Side effects are fine in a list comp, as long as you're making use of the return values. For instance, if you have a function that inserts a record to a database and returns the new ID, you could reasonably use a list comp to save a bunch of records and get a list of IDs for subsequent use. I hear what you are saying, but a list comprehension is a functional idiom. To mix functional and procedural idioms in the one expression is rather icky. Better to use one or the other but not both simultaneously. I'll accept that this is a weak recommendation though. In my opinion, trying to separate functional and procedural idioms is like trying to separate 'for' loops and recursion; they're two tools that can be used separately or together, in whatever way makes the most sense. Given that side-effecting functions are a mess in functional programming anyway, of course they cause problems for functional idioms; but if it's okay to have side effects at all, it ought to be okay to have side effects of a list comp. A list comp should take an (or several) input iterable(s) and produce an output list. My personal expectation is that it should step through the entire iterable, and every element of it should be eyeballed: if there's an 'if'' clause, they might not all produce output elements, but they all at least had a chance to. The input iterable and its contents shouldn't be changed in the process, other than being consumed (if it's a one-shot iterator/generator). Side effects are fine, just as long as the output list is important to the code. Of course, that's just *my* expectation. As we've seen before, expectations can differ; several of us believe that while x: implies that x is able to become false (either through mutation or through rebinding) during the loop, and others see it as equally viable for it to mean if x: while True:. I suspect our various backgrounds influence our Python styles fairly strongly. And that's a good thing - we aren't all forced into one style. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
On Tue, Dec 23, 2014 at 3:23 AM, Grant Edwards invalid@invalid.invalid wrote: Heh. I once worked on a C++ project that included its own crypo code (i.e. custom implementations of things like AES and SHA-1). Damn. Should I ever start to do something like that (for a real product), I hereby officially request that somebody please try to slap some sense into me. Likewise. And I'll happily do the slapping. There's one exception. Writing your own crypto is a bad idea if that means reimplementing AES... but if you want something that's effective on completely different levels, sometimes it's best to write your own. I had a project a while ago that needed some encryption work done, and I implemented something that I described as scarily effective. My boss demanded that the debug code-execution feature be protected by a password that would be strong even if someone could read the source code, so I put together something that would hash the incoming password, then check to see if the first two and last two bytes of the hash were all the same byte value as the current hour-of-week (ranging from 0 to 167). This is clearly more secure than simply embedding a SHA256 hash in the source code, because you can't possibly reverse-engineer it (since you don't even have the full hash). And yes, this was 100% effective in convincing my boss that the code executor was safely guarded. Since that was the goal, having several lines of complex and opaque code was far better than a single line that says if hash(password)=='5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8': do stuff, which is way too easy for someone to decode. And it was, indeed, scarily effective. That lasted for a long time, and any time there was a question about security, I could just point to that and say See? Safe ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: very weird pandas behavior
On Tue, Dec 23, 2014 at 3:47 AM, Dave Angel da...@davea.name wrote: (I lied. I kept Windows, in a Virtualbox, so I can resurrect it on demand) You remind me of the evil sorcerers who keep their defeated foes around in undead form, so they can torment them whenever they feel like it. Only difference is, resurrecting Windows doesn't torment Windows, it torments you... WHY doesn't my program work properly here? It ought to! ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: List Comprehensions
On Monday, December 22, 2014 8:37:50 PM UTC+5:30, Chris Angelico wrote: On Tue, Dec 23, 2014 at 1:58 AM, Rustom Mody wrote: If you consider side-effecting comprehensions as kosher, then a next conclusion is naturally going to be that multiple generator comprehensions are confusing and therefore not kosher -- a very unfortunate conclusion IMHO. Why does that follow? What has that to do with side effects? A comprehension means two things 1. There is the standard de-sugaring in terms of for-loops given in the docs that Steven repeated above. 2.There is this picture (needs to be seen in fix-pitch font) [f(x) for x in [x₁ x₂ x₃ … xₙ]] means [x₁ x₂ x₃ … xₙ] ↓ ↓ ↓ ↓ [fx₁ fx₂ x₃ … fxₙ] There are not just two different ways of writing that for-loop -- upwards and downwards -- there are n! ways. And even that assumes that each arrow is atomically and sequentially performed. An assumption quite ok for a sequential machine completely unnecessary for a programmer. Give up that assumption and the ways are infinite IOW the second view is more abstract and programmer friendly than the first in the same way that saying the C expression x+1 Adds 1 to the variable x rather than saying Its the C version of add 1, %eax [Why not inc %eax ?] And this despite the fact that mathematical integers and real are rather far removed from C's int and float. IOW white lies are preferable to exact precise gobbledygook. If the semantics of the comprehension depends on the order of the arrows, the comprehension is screwed Shorter technological answer: In Haskell a side-effecting function gets a monadic type -- the type carries the moniker I am side-effecting and so it cant be put in to a comprehension without type errors. Now python's type system cannot do what Haskell's can [for better or worse is another matter -- a strong type system can be neat or a pain] Considering that python's comprehensions are cloned from Haskell, it seems fair that Haskell's formal strictures be passed on to beginners at least informally -- https://mail.python.org/mailman/listinfo/python-list
Re: what is wrong with d.clear()?
On Monday, December 22, 2014 12:16:15 AM UTC-8, shawool wrote:
Hi,
where am i going wrong ?
$ python3
Python 3.2.5 (default, Oct 2 2013, 22:58:11)
[GCC 4.8.1] on cygwin
Type help, copyright, credits or license for more information.
d = {}
import sys
d = sys.modules
type(d)
class 'dict'
dir(d)
['__class__', '__contains__', '__delattr__', '__delitem__', '__doc__',
'__eq__', '__format__', '__ge__', '__getattribute__', '__getitem__',
'__gt__', '__hash__', '__init__', '__iter__', '__le__', '__len__', '__lt__',
'__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__',
'__setattr__', '__setitem__', '__sizeof__', '__str__', '__subclasshook__',
'clear', 'copy', 'fromkeys', 'get', 'items', 'keys', 'pop', 'popitem',
'setdefault', 'update', 'values']
d.clear()
Traceback (most recent call last):
File stdin, line 1, in module
d
Traceback (most recent call last):
File stdin, line 1, in module
quit()
Traceback (most recent call last):
File stdin, line 1, in module
Thanks in advance.
Best regards,
Shawool
Is there a reason you're composing your messages with a large, colored font?
Shit's obnoxious, yo.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
On 22/12/2014 15:39, Skip Montanaro wrote: On Mon, Dec 22, 2014 at 9:22 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info mailto:steve%2bcomp.lang.pyt...@pearwood.info wrote: Don't try this at home! # download_naked_pictures_of_jennifer_lawrence.py import os os.system(rm ――rf /) And because Steven *knows* some fool will try this at home, he cripples the rm command. Now where's the fun in that? :-) Skip I don't see any fun anywhere in this at all. How can one import and one os.system() call do any damage to anything? I'm guessing that rm is Bob Martin but who is rf? Shouldn't that be a backslash '\' on Windows? -- 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: Hello World
On 22/12/2014 16:23, Grant Edwards wrote: On 2014-12-21, Roy Smith r...@panix.com wrote: In article 54974ed7$0$12986$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Obviously you don't write obfuscated code like this for production use, except in such cases where you deliberately want to write obfuscated code for production use. Heh. I once worked on a C++ project that included its own crypo code (i.e. custom implementations of things like AES and SHA-1). Damn. Should I ever start to do something like that (for a real product), I hereby officially request that somebody please try to slap some sense into me. I'm having wonderful thoughts of Michael Palin's favourite Python sketch which involved fish slapping. -- 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: Hello World
On 2014-12-22 18:51, Mark Lawrence wrote: On 22/12/2014 16:23, Grant Edwards wrote: On 2014-12-21, Roy Smith r...@panix.com wrote: In article 54974ed7$0$12986$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Obviously you don't write obfuscated code like this for production use, except in such cases where you deliberately want to write obfuscated code for production use. Heh. I once worked on a C++ project that included its own crypo code (i.e. custom implementations of things like AES and SHA-1). Damn. Should I ever start to do something like that (for a real product), I hereby officially request that somebody please try to slap some sense into me. I'm having wonderful thoughts of Michael Palin's favourite Python sketch which involved fish slapping. Well, ChrisA _has_ mentioned Pike in this thread. :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
On Mon, 22 Dec 2014 16:18:33 +, Grant Edwards wrote: On 2014-12-21, Tony the Tiger tony@tiger.invalid wrote: On Sat, 20 Dec 2014 23:57:08 +1100, Steven D'Aprano wrote: I am in total awe. I'm not. It has no real value. Write your code like that and you'll soon be looking for a new job. I think you'll find that people who know enough to write code like that only do it for entertainment purposes. Some of the articles on the daily wtf suggest otherwise -- I'd rather have a free bottle in front of me than a prefrontal lobotomy. -- Fred Allen [Also attributed to S. Clay Wilson. Ed.] -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
On 2014-12-22 19:05, MRAB wrote: On 2014-12-22 18:51, Mark Lawrence wrote: I'm having wonderful thoughts of Michael Palin's favourite Python sketch which involved fish slapping. Well, ChrisA _has_ mentioned Pike in this thread. :-) But you know he does it just for the halibut... -tkc -- https://mail.python.org/mailman/listinfo/python-list
Encryption - was Hello World
On 12/22/2014 12:25 PM, Chris Angelico wrote: There's one exception. Writing your own crypto is a bad idea if that means reimplementing AES... but if you want something that's effective on completely different levels, sometimes it's best to write your own. I had a project a while ago that needed some encryption work done, and I implemented something that I described as scarily effective. My boss demanded that the debug code-execution feature be protected by a password that would be strong even if someone could read the source code, so I put together something that would hash the incoming password, then check to see if the first two and last two bytes of the hash were all the same byte value as the current hour-of-week (ranging from 0 to 167). This is clearly more secure than simply embedding a SHA256 hash in the source code, because you can't possibly reverse-engineer it (since you don't even have the full hash). And yes, this was 100% effective in convincing my boss that the code executor was safely guarded. Since that was the goal, having several lines of complex and opaque code was far better than a single line that says if hash(password)=='5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8': do stuff, which is way too easy for someone to decode. And it was, indeed, scarily effective. That lasted for a long time, and any time there was a question about security, I could just point to that and say See? Safe I figure I must be misunderstanding something in your explanation, since a brute-force password guesser would seem to only need four billion tries to (probably) crack that. 1) Are you assuming that the cracker can read the source code, but cannot modify the version of the code that is running? 2) Are you really doing something equivalent to: test = time_calc() - get a one-byte byte-string according to hour of the week encoded_pw = hash(password) if encoded_pw.startswith(test*2) and encoded_pw.endswith(test*2): ---passed--- I can understand that being sufficiently obscure for the pointy haired boss, but I figure I've got to be missing something. A quick test with 3.2 shows that around a million hashes can be generated per second, so checking four billion is only an hour or so. Since some of them will collide, that gives us something better than 50% likelihood of having found a useful pw in an hour. But a few more hours and we'll most likely have it. For that matter, you must have already written such a pw finder. I'm back to figuring I'm misunderstanding what you're saying. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Program calling unwanted functions
Hello to all those in this forum, My code seems to have a mind of its own. I have been writing a program to reenact the Twenny Wun Vine video, and it seems to be activating functions without me calling them. Here is the script: def kid(): print Cameraman: You stupid. kid1 = raw_input(Kid: ) if kid1.lower() == no im not or kid1.lower() == no i'm not.: print Cameraman: What's nine plus ten? kid2 = raw_input(Kid: ) if kid2.lower() == twenny wun or kid2.lower() == twenty-one or kid2.lower() == twenty one or kid2 == 21 or kid2.lower() == twenny one: print Cameraman: You stupid. Ending program... else: print That is not the right quote. kid() else: print That is not the right quote. kid() def cameraman(): cameraman1 = raw_input(Cameraman: ) if cameraman1.lower() == you stupid: print Kid: No I'm not. cameraman2 = raw_input(Cameraman: ) if cameraman2.lower() == whats 9 + 10 or cameraman2.lower() == whats nine plus ten: print Kid: Twenny wun cameraman3 = raw_input(Cameraman: ) if cameraman3.lower() == you stupid: print Ending program... time.sleep(2) else: print That is not the right quote. cameraman() else: print That is not the right quote. cameraman() else: print That is not the right quote. cameraman() def perspective(): perspective_request = raw_input(Do you want to be the cameraman or the kid? (type the one you want): ) if perspective_request == cameraman: cameraman() if perspective_request == kid: kid() else: print Invalid input. perspective() def instructions(): instructions_request = raw_input(Do you want instructions? (type 'yes' or 'no' without the quotes): ) if instructions_request == no: perspective() if instructions_request == yes: print This is a reenactment of the 'Twenny Wun' Vine. You can type in the empty space to the right of each ':,' then press [return]. Don't use punctuation. perspective() else: print Invalid input. instructions() instructions() The cameraman function restarts itself when it ends, and the kid function calls instructions(). Does anyone know why? -- https://mail.python.org/mailman/listinfo/python-list
Re: Program calling unwanted functions
In b37a93ec-c90b-4375-a264-e96c31288...@googlegroups.com Luke Tomaneng luketoman...@gmail.com writes: The cameraman function restarts itself when it ends, and the kid function calls instructions(). Does anyone know why? The cameraman function restarts itself because ... that's what you told it to do. As far as I can see, every possible logic branch ends up with a call to cameraman(). The kid function doesn't call instructions, but the last line of your script does call it, unconditionally. -- John Gordon Imagine what it must be like for a real medical doctor to gor...@panix.comwatch 'House', or a real serial killer to watch 'Dexter'. -- https://mail.python.org/mailman/listinfo/python-list
Re: List Comprehensions
On 12/22/2014 12:10 PM, Chris Angelico wrote: On Tue, Dec 23, 2014 at 2:18 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Chris Angelico wrote: On Mon, Dec 22, 2014 at 8:21 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: If the called function has side-effects, a list comp is not a good solution. Hmm. I'm not so sure about that. Side effects are fine in a list comp, as long as you're making use of the return values. For instance, if you have a function that inserts a record to a database and returns the new ID, you could reasonably use a list comp to save a bunch of records and get a list of IDs for subsequent use. I hear what you are saying, but a list comprehension is a functional idiom. In particular, it is a way to hide the mutational, non-functional, .append that is a necessary part of constructing an array of references in contiguous memory on a physical machine. To mix functional and procedural idioms in the one expression is rather icky. A list comp with side-effects in the target expression is definitely a subversion of the original intent. Whether Python programmers should respect that intent is another matter. Limiting the opinion/recommendation to single expressions makes it more defensible than something broader. Better to use one or the other but not both simultaneously. I'll accept that this is a weak recommendation though. In my opinion, trying to separate functional and procedural idioms is like trying to separate 'for' loops and recursion; they're two tools A for loop with a recursive call in its body is not 'one expression'. Moreover, it is easy to claim that driving multiple recursion with a for loop is clearer than using the recursive equivalent of a for loop to drive the 'horizontal' repetition. Untested example for preorder traversal of a tree where nodes have ordered children: def preorder(node): yield node for child in node.children(): # horizontal repetition yield from preorder(child) # vertically nested repetition I do not see any such gain over Ganesh Pal's original for-loop code. that can be used separately or together, in whatever way makes the most sense. Given that side-effecting functions are a mess in functional programming anyway, of course they cause problems for functional idioms; but if it's okay to have side effects at all, it ought to be okay to have side effects of a list comp. I see this as equivalent to If it is okay to have separated side effects, it ought to be okay to have mixed-in side effects. I am not claiming that I would *never* use side effects in a list comp, but I am sympathetic to the objection. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Program calling unwanted functions
On 12/22/2014 02:55 PM, Luke Tomaneng wrote: Hello to all those in this forum, Hello. When starting a thread, please tell us your environment. In this case, it would be the python version and OS. My code seems to have a mind of its own. I have been writing a program to reenact the Twenny Wun Vine video, and it seems to be activating functions without me calling them. Here is the script: def kid(): print Cameraman: You stupid. kid1 = raw_input(Kid: ) if kid1.lower() == no im not or kid1.lower() == no i'm not.: print Cameraman: What's nine plus ten? kid2 = raw_input(Kid: ) if kid2.lower() == twenny wun or kid2.lower() == twenty-one or kid2.lower() == twenty one or kid2 == 21 or kid2.lower() == twenny one: print Cameraman: You stupid. Ending program... else: print That is not the right quote. kid() else: print That is not the right quote. kid() def cameraman(): cameraman1 = raw_input(Cameraman: ) if cameraman1.lower() == you stupid: print Kid: No I'm not. cameraman2 = raw_input(Cameraman: ) if cameraman2.lower() == whats 9 + 10 or cameraman2.lower() == whats nine plus ten: print Kid: Twenny wun cameraman3 = raw_input(Cameraman: ) if cameraman3.lower() == you stupid: print Ending program... time.sleep(2) else: print That is not the right quote. cameraman() else: print That is not the right quote. cameraman() else: print That is not the right quote. cameraman() def perspective(): perspective_request = raw_input(Do you want to be the cameraman or the kid? (type the one you want): ) if perspective_request == cameraman: cameraman() if perspective_request == kid: kid() else: print Invalid input. perspective() def instructions(): instructions_request = raw_input(Do you want instructions? (type 'yes' or 'no' without the quotes): ) if instructions_request == no: perspective() if instructions_request == yes: print This is a reenactment of the 'Twenny Wun' Vine. You can type in the empty space to the right of each ':,' then press [return]. Don't use punctuation. perspective() else: print Invalid input. instructions() instructions() The cameraman function restarts itself when it ends, and the kid function calls instructions(). Does anyone know why? The kid() function doesn't call instructions, you do. On that last line. However all of your functions are recursive, and do not do what you expect them to. You're using the function call as though it were a goto, and that's not correct in Python (or in C, or C++, Java, or most any other common language). Recursion in your case is where you call a function from within the same function. It could also occur as mutual recursion, where function A calls B, and B in turn calls A. I'll pick on one function first, called instructions(). If the user types something invalid, you print Invalid input. and call the function again. In this case, because the call is at the end, no harm is usually done, but it would be tricky to explain why. If the user happened to type the wrong input 1000 times, you'd hit a recursion limit and crash, but that's unlikely unless you have a very stubborn user. The right way to express what is needed is to use a while loop. def instructions(): while True: instructions_request = raw_input(Do you want instructions? (type 'yes' or 'no' without the quotes): ) if instructions_request == no: perspective() return if instructions_request == yes: print This is a reenactment of the 'Twenny Wun' Vine. You can type in the empty space to the right of each ':,' then press [return]. Don't use punctuation. perspective() return else: print Invalid input. Most of the other functions can be fixed in a similar way. Your complaint about the cameraman function is a bit strange, since the function never ends. It always calls itself. if you've got a place where it should, and that place is not physically on the last line of the function, you probably need to say return at that point. It might help if you tell us what programming language you used before, so we can show the differences in the way these things might be handled. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: what is wrong with d.clear()?
On Monday, December 22, 2014 12:16:03 PM UTC-6, sohca...@gmail.com wrote: On Monday, December 22, 2014 12:16:15 AM UTC-8, shawool wrote: [snip: OP's adolescent accessorizing] @_@ Is there a reason you're composing your messages with a large, colored font Shit's obnoxious, yo. Whilst i don't share shawool's penchant of utilizing the brutish urban vernacular, i must agree that he has a valid point. Please don't be tempted to use large fonts (or very small fonts), typically anything around 12 pts will suffice. Also, using any font color besides black, or background color besides white, should be limited except to *VERY* rare occasions. If you think that by using a large font and bright color for you whole post that your question is more likely to stand out, then you are correct, but it most likely stand out in a negative way. I feel it just as annoying as someone who constantly bumps a thread even when no one is responding. -- https://mail.python.org/mailman/listinfo/python-list
Re: what is wrong with d.clear()?
On Monday, December 22, 2014 12:54:55 PM UTC-8, Rick Johnson wrote: On Monday, December 22, 2014 12:16:03 PM UTC-6, sohca...@gmail.com wrote: On Monday, December 22, 2014 12:16:15 AM UTC-8, shawool wrote: [snip: OP's adolescent accessorizing] @_@ Is there a reason you're composing your messages with a large, colored font Shit's obnoxious, yo. Whilst i don't share shawool's penchant of utilizing the brutish urban vernacular, i must agree that he has a valid point. Please don't be tempted to use large fonts (or very small fonts), typically anything around 12 pts will suffice. Also, using any font color besides black, or background color besides white, should be limited except to *VERY* rare occasions. I would argue that you should never use *ANY* formatting. No font size changes. No colors. No fonts. If you need to set a larger font because you have difficulty reading, then just change your client's display font. There's no need to compose messages that send HTML to override how other people see your message. It's just rude, since they might have their client set to use a specific font size when viewing messages, and you've just overridden it for selfish reasons. Special cases aren't special enough to break the rules. If you think that by using a large font and bright color for you whole post that your question is more likely to stand out, then you are correct, but it most likely stand out in a negative way. I feel it just as annoying as someone who constantly bumps a thread even when no one is responding. Absolutely agreed. -- https://mail.python.org/mailman/listinfo/python-list
Re: what is wrong with d.clear()?
On 12/22/2014 04:19 PM, sohcahto...@gmail.com wrote: On Monday, December 22, 2014 12:54:55 PM UTC-8, Rick Johnson wrote: On Monday, December 22, 2014 12:16:03 PM UTC-6, sohca...@gmail.com wrote: On Monday, December 22, 2014 12:16:15 AM UTC-8, shawool wrote: [snip: OP's adolescent accessorizing] @_@ Is there a reason you're composing your messages with a large, colored font Shit's obnoxious, yo. Whilst i don't share shawool's penchant of utilizing the brutish urban vernacular, i must agree that he has a valid point. Please don't be tempted to use large fonts (or very small fonts), typically anything around 12 pts will suffice. Also, using any font color besides black, or background color besides white, should be limited except to *VERY* rare occasions. I would argue that you should never use *ANY* formatting. No font size changes. No colors. No fonts. If you need to set a larger font because you have difficulty reading, then just change your client's display font. There's no need to compose messages that send HTML to override how other people see your message. It's just rude, since they might have their client set to use a specific font size when viewing messages, and you've just overridden it for selfish reasons. Special cases aren't special enough to break the rules. If you think that by using a large font and bright color for you whole post that your question is more likely to stand out, then you are correct, but it most likely stand out in a negative way. I feel it just as annoying as someone who constantly bumps a thread even when no one is responding. Absolutely agreed. Or even better: Don't use html email for forum messages. It frequently messes up the colors, the font, the formatting (like indentation), or even prevents some people from even seeing and/or replying to the message. Put the email program in text mode, and just send what you want people to see. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: very weird pandas behavior
On Monday, December 22, 2014 9:56:11 AM UTC-6, ryguy7272 wrote: I've been using Python for quite a few years now an i can only once remember using any type of python installation tools (easy_install or pip... puke!). I've always found the easiest route to be just downloading a zip/tar file, and then extracting it into my PythonXX/Lib/SitePackages directory -- of course, not without inspecting the source code first!!! To everyone else, I'm going back to VBA, VB, C#, Java, SQL, SSIS, R, Matlab, simply because all of those work perfectly fine. [...] Learning Python was both fun frustrating. If you need to waste time, work with Python. If you need to do real work, use any on the following: VBA, VB, C#, Java, SQL, R, Matlab. Well if you're coming from *that* background then Python is not going to make sense to you. VB has the power to ruin almost anyone. Naive folks tend to believe that if a language offers a Graphical front-end then that language must be more advanced...HA! When i see a graphical GUI builder i run the other direction screaming because i know that graphic builders *ONLY* exist as shoe polish for turdious API's Polish a turd, it's still a turd! Now don't get me wrong, i understand the *vital* importance of abstractions, and without them, even the smallest programs would require more finger gymnastics than a mortal human could endure. But there *MUST* be a balance drawn between high level and low level API's, because as you ascend up the abstraction scale, you may feel good for a while, but eventually you will find yourself trapped in a prison API of claustrophobia You could say that Graphical GUI builders are the highest possible abstraction, and you would be correct, but it's not the mere fact that they are high level that i find troublesome, no, because *ANY* text based API could be abstracted to a level that becomes suitable for even the laziest programmer, it the fact that they shield you from the architecture of the underlying code, and what inevitably happens is that you find yourself needing a functionality that the Graphical interface does not provide, for which the only solution is sit down and learn the API you have so desperately tried to avoid. Anyone care for a piping hot cup of irony? I just uninstalled Python and deleted 15 Python books that I found online. That seems excessive. I'm sorry but if you need 15 books to learn how to write Python code, and you already had prior programming experience, then i am going to say that Python is definitely not for you. Instead of taking the graphical route and attempting to shield you from the harsh realities of life, Python has devoted all it's energy to providing a clean syntax, an integrated documentation capability (via doc strings on the code author's side, and and the help() function on the users side), interactivity, introspection, and a quite extensive stdlib. Granted Python has it's warts, and i'm not here to apologize for *ANY* them, but all in all it's a damn good language that allows me to be far more productive than any other language has. No language can be perfect, but giving up on Python because you could not get a 3rd party package to install is quite ridiculous. I mean, if you were dumping it because of it's shameless herd-conformity to the Unicode standard then AT LEAST that would make sense me! -- https://mail.python.org/mailman/listinfo/python-list
Re: Encryption - was Hello World
On Tue, Dec 23, 2014 at 6:57 AM, Dave Angel d...@davea.name wrote: I figure I must be misunderstanding something in your explanation, since a brute-force password guesser would seem to only need four billion tries to (probably) crack that. 1) Are you assuming that the cracker can read the source code, but cannot modify the version of the code that is running? 2) Are you really doing something equivalent to: test = time_calc() - get a one-byte byte-string according to hour of the week encoded_pw = hash(password) if encoded_pw.startswith(test*2) and encoded_pw.endswith(test*2): ---passed--- I can understand that being sufficiently obscure for the pointy haired boss, but I figure I've got to be missing something. A quick test with 3.2 shows that around a million hashes can be generated per second, so checking four billion is only an hour or so. Since some of them will collide, that gives us something better than 50% likelihood of having found a useful pw in an hour. But a few more hours and we'll most likely have it. For that matter, you must have already written such a pw finder. I'm back to figuring I'm misunderstanding what you're saying. No, actually you're understanding that fairly well. Of course, I didn't share the password finder script. The code was similar in functionality to what you describe, but it used a more obscure coding style so it wasn't obvious. Imagine using a regex to verify that part of the hash. (It wasn't actually a regex, but it wasn't Python either, and the significance is that it was obfuscated code.) I don't remember exactly which hashing algorithm I was using for this, but the password finder took about a week (running roughly eight hours a day, while I was there) to cover most of the required passwords. As to the assumptions... uhh... that was never something I really understood. I think you're probably right, and this was part of the paranoia of my code might be stolen. You're attempting to attribute a level of logic to the requirements which has no supporting evidence :) But what you've proven above is how ineffective this technique is at keeping out a determined, and mathematically-adept, attacker. Yaknow, *real* security. This code was *extremely* effective at satisfying my boss. As I said, he wasn't satisfied with the idea of just embedding a SHA256 hash into the code; I would have used an XKCD 936 compliant password, so brute-forcing that would take (assuming your million-hashes-per-second figure) about a year, and that assuming the attacker knew my exact style. Aside: XKCD 936 overestimates the time to generate guesses (1000/sec), which presumably means it's not talking about reversing a hash, but attempting some other attack. (Not a big deal, since the same figure is used for both types of password.) But it also underestimates the password entropy of four words. Let's see. First off, a 4K corpus isn't that hard to work with, so that potentially gives you another four bits of entropy; in /usr/share/dict/words I have 72861 words with no capital letters, punctuation, etc, so it wouldn't be unreasonable to push that up even to 16 bits per word (which sounds weird, worded like that), raising the total entropy from 44 bits to 64. And there's no guarantee that one person's corpus will exactly match another's. Plus, you might and might not capitalize the first letters of the words (another bit), and you could run them together with no punctuation, or use any common punctuation to separate them (space, or -:,./\ - eight easy options, 3 bits). So in theory, an attacker might know that you're using an XKCD 936 password, but there could still be up to 68 bits of entropy, *easily*. Even in a dedicated personal attack, the estimate of 44 bits would be an absolute minimum, and it's likely to cost rather more than that. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: very weird pandas behavior
On Tue, Dec 23, 2014 at 9:15 AM, Rick Johnson rantingrickjohn...@gmail.com wrote: I mean, if you were dumping it because of it's shameless herd-conformity to the Unicode standard then AT LEAST that would make sense me! Wait, which of our trolls are you? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
TypeError: unhashable type: 'list'
I am getting an exception that the traceback looks like:
Traceback (most recent call last):
File C:\Projects\QA\robot_20141103\resources\assessment_utilities.py, line
29, in create_new_project
program = customer.add(program_code)
File C:\Projects\QA\robot_20141103\resources\assessment_customer.py, line
589, in add
program = ProgramMaker.Code2Program(program_code, self)
File C:\Projects\QA\robot_20141103\resources\programmaker.py, line 25, in
Code2Program
'ASSESS_PPL' : PPL(customer)
File C:\Projects\QA\robot_20141103\resources\ppl.py, line 20, in __init__
MeasureMaker.Code2Measure('Furnace Whistle', self)
TypeError: unhashable type: 'list'
My problem is that I am not sure what the problem is. I can check the type of
'self' which is an object and the string 'Furnace Whistle' is obviously not a
list. The static function 'MeasureMaker.Code2Measure' is a simple factory:
class MeasureMaker:
def Code2Measure(measure_code, core):
try:
return {
...
'Furnace Whistle': FurnaceWhistle(core)
}[measure_code]
except KeyError as error:
return None
Code2Measure = staticmethod(Code2Measure)
What is the 'list' that is in the exception? Or how do I find out?
Thank you.
Kevin
--
https://mail.python.org/mailman/listinfo/python-list
Re: Encryption - was Hello World
On 12/22/2014 05:29 PM, Chris Angelico wrote: On Tue, Dec 23, 2014 at 6:57 AM, Dave Angel d...@davea.name wrote: I figure I must be misunderstanding something in your explanation, since a brute-force password guesser would seem to only need four billion tries to (probably) crack that. snip As to the assumptions... uhh... that was never something I really understood. I think you're probably right, and this was part of the paranoia of my code might be stolen. You're attempting to attribute a level of logic to the requirements which has no supporting evidence :) I recall a DLL that implemented the license check, and an application called a function in the DLL and looked for true or false. Even the exported function name was a pretty good clue. And extremely easy to intercept and defeat. I did convince the company (my employer, though I didn't normally work on the license stuff) to statically link instead. And to stop shipping all the symbols with the executable. Most security flaws are of this form, not sophisticated cracking. I also wrote my own form of protection in 1976 to make it difficult for somebody to retrieve source. The previous version had simply added a protect bit to the image file. Mine saved a completely different file every time you re-saved the program data, to try to make it hard (not impossible) to recover it. Then it stored a separate key in each sector of the file so reading it into the interpreter was always possible. I had a couple of constraints - the file couldn't grow, and it had to be fast enough to have no impact on load time. I had a guy claim that the CIA got interested in the code, and cracked it during a lunch hour. But I suspect somebody got hold of the source code, which was available to our field service staff. There were a couple of iterations before this code was stable. Not in the algorithm, but in what amounted to a few back-doors. For example, it turns out the error display logic would show the line in error, unencrypted. So people would munge the code sufficiently to cause errors on most lines, and retrieve them one at a time. Another thing I did in 1976 which was apparently unusual was to add a checksum to the code itself. The Boot Rom would self-check before starting the machine, and it also checksummed the loadable microcode before passing control to it. Prevented some corruption problems. Another thing that machine did was to run a RAM diagnostic from the time it booted till the operator specified the drive from which to fetch the microcode. The entire test took many minutes to run, but it was entirely silent unless a problem occurred. No pass counts or anything. When I added that code, manufacturing found some machines that had been put aside as flaky, actually had RAM errors. The test was necessary crude, because the entire boot, including disk logic, had to fit in 1k. Ahh... memories. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: TypeError: unhashable type: 'list'
On Tue, Dec 23, 2014 at 10:10 AM, ronald.kevin.bur...@gmail.com wrote:
My problem is that I am not sure what the problem is. I can check the type of
'self' which is an object and the string 'Furnace Whistle' is obviously not a
list. The static function 'MeasureMaker.Code2Measure' is a simple factory:
class MeasureMaker:
def Code2Measure(measure_code, core):
try:
return {
...
'Furnace Whistle': FurnaceWhistle(core)
}[measure_code]
except KeyError as error:
return None
Code2Measure = staticmethod(Code2Measure)
What is the 'list' that is in the exception? Or how do I find out?
Does your MeasureMaker class define a __hash__ method? If so, what's
its definition? Possibly that's using some attributes and one of those
is a list.
Incidentally, is this actually how your code is laid out? What Python
versions do you need to support? Unless this code has to run on 2.3 or
earlier, you can replace the staticmethod call with a decorator:
@staticmethod
def Code2Measure(measure_code, core):
... code as above, but without the reassignment at the end ...
And if you were running this on 2.3, the except KeyError as error
syntax would be invalid anyway, so this should be a safe change :)
(You don't even need that try/except block, actually. If you use the
dict's .get() method, it'll return None instead of raising KeyError,
which is exactly what you need here.)
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: TypeError: unhashable type: 'list'
On 12/22/2014 06:10 PM, ronald.kevin.bur...@gmail.com wrote:
I am getting an exception that the traceback looks like:
Traceback (most recent call last):
File C:\Projects\QA\robot_20141103\resources\assessment_utilities.py, line
29, in create_new_project
program = customer.add(program_code)
File C:\Projects\QA\robot_20141103\resources\assessment_customer.py, line
589, in add
program = ProgramMaker.Code2Program(program_code, self)
File C:\Projects\QA\robot_20141103\resources\programmaker.py, line 25, in
Code2Program
'ASSESS_PPL' : PPL(customer)
File C:\Projects\QA\robot_20141103\resources\ppl.py, line 20, in __init__
MeasureMaker.Code2Measure('Furnace Whistle', self)
TypeError: unhashable type: 'list'
My problem is that I am not sure what the problem is. I can check the type of
'self' which is an object and the string 'Furnace Whistle' is obviously not a
list. The static function 'MeasureMaker.Code2Measure' is a simple factory:
class MeasureMaker:
def Code2Measure(measure_code, core):
try:
return {
...
'Furnace Whistle': FurnaceWhistle(core)
}[measure_code]
except KeyError as error:
return None
Code2Measure = staticmethod(Code2Measure)
What is the 'list' that is in the exception? Or how do I find out?
I don't see enough pieces to tell the problem at all. The two lowest
levels of stack trace are on line 20 and 25, and you don't include
either of those in your fragments. Further, since many of your
statements are multi-statement lines, the problem isn't necessarily
showing in the stack trace, which only shows one line of the offending
statement.
Finally, I suspect PPL is some form of alias, which you don't show
either. And the stack trace shows four different source files.
Probably only the last two matter, but it'd be very useful to see the
class/function definitions involved in their entirety, plus any from
xxx import yyy type aliases that may be relevant.
Are you perhaps using Python 2.x ? If so, you want to inherit from
object. I doubt that's your problem, but it's a missing clue. Always
state your Python version when describing a new problem.
BTW, using @staticmethod decorator is usually clearer than the way you
have it here. But that's no bug either.
--
DaveA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Program calling unwanted functions
On Dec 22, 2014 2:37 PM, Dave Angel da...@davea.name wrote: I'll pick on one function first, called instructions(). If the user types something invalid, you print Invalid input. and call the function again. In this case, because the call is at the end, no harm is usually done, but it would be tricky to explain why. If the user happened to type the wrong input 1000 times, you'd hit a recursion limit and crash, but that's unlikely unless you have a very stubborn user. Point of interest, Python (or at least CPython) doesn't optimize tail-call recursion, so in fact this sort of unbounded recursion (a stack leak, if you will) is equally bad no matter where it appears in the function. -- https://mail.python.org/mailman/listinfo/python-list
Re: Program calling unwanted functions
On 12/22/2014 06:48 PM, Ian Kelly wrote: On Dec 22, 2014 2:37 PM, Dave Angel da...@davea.name wrote: I'll pick on one function first, called instructions(). If the user types something invalid, you print Invalid input. and call the function again. In this case, because the call is at the end, no harm is usually done, but it would be tricky to explain why. If the user happened to type the wrong input 1000 times, you'd hit a recursion limit and crash, but that's unlikely unless you have a very stubborn user. Point of interest, Python (or at least CPython) doesn't optimize tail-call recursion, so in fact this sort of unbounded recursion (a stack leak, if you will) is equally bad no matter where it appears in the function. Which is exactly why I mentioned the recursion limit of about 1000. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: Program calling unwanted functions
On Monday, December 22, 2014 3:57:31 PM UTC-8, Dave Angel wrote: On 12/22/2014 06:48 PM, Ian Kelly wrote: On Dec 22, 2014 2:37 PM, Dave Angel da...@davea.name wrote: I'll pick on one function first, called instructions(). If the user types something invalid, you print Invalid input. and call the function again. In this case, because the call is at the end, no harm is usually done, but it would be tricky to explain why. If the user happened to type the wrong input 1000 times, you'd hit a recursion limit and crash, but that's unlikely unless you have a very stubborn user. Point of interest, Python (or at least CPython) doesn't optimize tail-call recursion, so in fact this sort of unbounded recursion (a stack leak, if you will) is equally bad no matter where it appears in the function. Which is exactly why I mentioned the recursion limit of about 1000. -- DaveA Python 2.7.3 (default, Dec 4, 2012, 17:28:13) [GCC 4.4.5 20110214 (Red Hat 4.4.5-6)] on linux2 Type help, copyright, credits or license for more information. def test(t): ... print(t) ... test(t+1) ... test(1) 1 2 3 4 snip 998 999 Traceback (most recent call last): File stdin, line 1, in module File stdin, line 3, in test File stdin, line 3, in test File stdin, line 3, in test snip File stdin, line 3, in test File stdin, line 3, in test RuntimeError: maximum recursion depth exceeded Huh...there actually is a limit of about 1,000. I'm assuming this is hard-coded? I did a similar test with Java a while back and was getting different results every time. -- https://mail.python.org/mailman/listinfo/python-list
Re: Program calling unwanted functions
On Dec 22, 2014 6:06 PM, sohcahto...@gmail.com wrote: Huh...there actually is a limit of about 1,000. I'm assuming this is hard-coded? I did a similar test with Java a while back and was getting different results every time. The default is 1000 but it can be configured with sys.setrecursionlimit. I think Java only uses a memory limit, not a frame limit. -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
In article mailman.17133.1419276169.18130.python-l...@python.org, Tim Chase python.l...@tim.thechases.com wrote: On 2014-12-22 19:05, MRAB wrote: On 2014-12-22 18:51, Mark Lawrence wrote: I'm having wonderful thoughts of Michael Palin's favourite Python sketch which involved fish slapping. Well, ChrisA _has_ mentioned Pike in this thread. :-) But you know he does it just for the halibut... Are you guys fishing for complements? -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
On Tue, Dec 23, 2014 at 11:55 AM, Roy Smith r...@panix.com wrote: In article mailman.17133.1419276169.18130.python-l...@python.org, Tim Chase python.l...@tim.thechases.com wrote: On 2014-12-22 19:05, MRAB wrote: On 2014-12-22 18:51, Mark Lawrence wrote: I'm having wonderful thoughts of Michael Palin's favourite Python sketch which involved fish slapping. Well, ChrisA _has_ mentioned Pike in this thread. :-) But you know he does it just for the halibut... Are you guys fishing for complements? That has nothing to do with it, it's just a red herring! ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
On Monday, December 22, 2014 4:56:13 PM UTC-8, Roy Smith wrote: In article mailman.17133.1419276169.18130.python-l...@python.org, Tim Chase python.l...@tim.thechases.com wrote: On 2014-12-22 19:05, MRAB wrote: On 2014-12-22 18:51, Mark Lawrence wrote: I'm having wonderful thoughts of Michael Palin's favourite Python sketch which involved fish slapping. Well, ChrisA _has_ mentioned Pike in this thread. :-) But you know he does it just for the halibut... Are you guys fishing for complements? I never thought I'd get cod in a pun thread outside of reddit. -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
On 2014-12-23 01:03, sohcahto...@gmail.com wrote: On Monday, December 22, 2014 4:56:13 PM UTC-8, Roy Smith wrote: In article mailman.17133.1419276169.18130.python-l...@python.org, Tim Chase python.l...@tim.thechases.com wrote: On 2014-12-22 19:05, MRAB wrote: On 2014-12-22 18:51, Mark Lawrence wrote: I'm having wonderful thoughts of Michael Palin's favourite Python sketch which involved fish slapping. Well, ChrisA _has_ mentioned Pike in this thread. :-) But you know he does it just for the halibut... Are you guys fishing for complements? I never thought I'd get cod in a pun thread outside of reddit. And a programming newsgroup isn't really the plaice for it anyway! -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
On Tue, Dec 23, 2014 at 12:37 PM, MRAB pyt...@mrabarnett.plus.com wrote: And a programming newsgroup isn't really the plaice for it anyway! And yet we do carp on a bit, don't we... ChrisA -- https://mail.python.org/mailman/listinfo/python-list
OFF TOPIC Snow Crash [was Re: Hello World]
Chris Angelico wrote: On Tue, Dec 23, 2014 at 12:15 AM, Roy Smith r...@panix.com wrote: If I really didn't trust something, I'd go to AWS and spin up one of their free-tier micro instances and run it there :-) How do you know it won't create console output that stroboscopically infects you with a virus through your eyes? Because that's *totally* what would be done in the town of Eureka. Anybody in IT who hasn't read Neal Stephenson's Snow Crash needs to hand in their Geek Card immediately. Snow Crash is nearly 20 years old now but still as much of a ripping yarn today as it was the year it was written. Under-achiever, freelance hacker and part-time pizza delivery boy for the Mafia, Hiro Protagonist, discovers that somebody has written a virus that hacks into computer programmers' brains via their optic nerve. This book has drama, adventure, humour, vast amounts of exposition that might even be almost true, a murderous Inuit who is his own sovereign state (a *nuclear armed* sovereign state at that), Rat Things, Sumerian myths, Reverend Wayne's Pearly Gates franchise, one of the most spunky teenage protagonists I've ever read, and pirates listening to Reason. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: what is wrong with d.clear()?
sohcahto...@gmail.com wrote: Is there a reason you're composing your messages with a large, colored font? How do you know what font the OP is using to compose his text? I see his post in the font of my choosing, which for the record is DejaVu LGC Sans Mono 10, in black, on a white background. But if I was stupid enough to use Comic Sans 72 in light green on a pale pink background, or if the OP choose to use the same, why is that anyone's business but ours? Anyone who sets their mail or news client to render HTML messages by default is simply opening themselves to a world of hurt. Poor choices of font is only the beginning of what nasties the sender can do to you if you render HTML in your mail/news client. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: what is wrong with d.clear()?
Dave Angel wrote: Or even better: Don't use html email for forum messages. It frequently messes up the colors, the font, the formatting (like indentation), or even prevents some people from even seeing and/or replying to the message. Put the email program in text mode, and just send what you want people to see. I agree, but alas the horse has bolted and the idiots have taken over. We cannot stop the great mass of people sending HTML mail, but there is no reason why we have to *read* HTML email. Even today, most mail clients will send a plain text part that contains the same content as the HTML part, and any decent mail client can be set to prefer the plain text part in preference to rendering the HTML. For those few cases where there is no plain text part[1], the better mail clients (such as mutt) will include an option to dump the raw HTML to plain text, minus all the tags. Last but not least, for the *vanishingly small* number of cases that has no plain text part, and the formatting of the text dump is unreadable, or where the formatting of the HTML is actually essential to understanding the post, then you have a choice of pressing Delete on the message or rendering the HTML. But rendering HTML should never be the default. [1] Or worse, one of those shitty messages that include a plain text part that says Your mail program cannot read this email. Please upgrade to a better mail program. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
On 23/12/2014 01:39, Chris Angelico wrote: On Tue, Dec 23, 2014 at 12:37 PM, MRAB pyt...@mrabarnett.plus.com wrote: And a programming newsgroup isn't really the plaice for it anyway! And yet we do carp on a bit, don't we... ChrisA Gordon Bennett what have I started? You dangle a bit of bait and... -- 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: what is wrong with d.clear()?
On 12/22/2014 09:33 PM, Steven D'Aprano wrote: Dave Angel wrote: Or even better: Don't use html email for forum messages. It frequently messes up the colors, the font, the formatting (like indentation), or even prevents some people from even seeing and/or replying to the message. Put the email program in text mode, and just send what you want people to see. I agree, but alas the horse has bolted and the idiots have taken over. We cannot stop the great mass of people sending HTML mail, but there is no reason why we have to *read* HTML email. Even today, most mail clients will send a plain text part that contains the same content as the HTML part, and any decent mail client can be set to prefer the plain text part in preference to rendering the HTML. For those few cases where there is no plain text part[1], the better mail clients (such as mutt) will include an option to dump the raw HTML to plain text, minus all the tags. Last but not least, for the *vanishingly small* number of cases that has no plain text part, and the formatting of the text dump is unreadable, or where the formatting of the HTML is actually essential to understanding the post, then you have a choice of pressing Delete on the message or rendering the HTML. But rendering HTML should never be the default. [1] Or worse, one of those shitty messages that include a plain text part that says Your mail program cannot read this email. Please upgrade to a better mail program. I have set my regular email program (Thunderbird) to text only for years. But many times the conversion done by the sender's dumb email makes his message look good to him, and mine like garbage, with messed up indentation, modified characters, and so on. Further, I really tried to use a tablet, with a newsreader that is slowly changing to my wishes. But I've given up for a few months, and only check messages when my notebook compuater (with Thunderbird) is available. Sometime in the hopefully near future, I'll try an Android newsreader again, but reading html and responding when there's no quoting was just too painful. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
On Monday, December 22, 2014 3:04:52 PM UTC+5:30, Marko Rauhamaa wrote: Steven D'Aprano : Steve Hayes wrote: But what if I had run it and it reformatted my hard disk? How would I have known that it would or wouldn't do that? That's why I didn't run it myself :-) Well, I admit having run yum install python3 as root. Ultimately, I'm trusting the security of my operating system. Ultimately, I'm trusting my luck. O thats nothing. Ive eaten cookies. Given by strangers can contain narcotics you know! Ive even walked on the road. Mines? Youve heard of them right?!? People get their legs blown off [shivers] Only computers I dont use -- Just too dangerous. If cars and bikes can have bombs -- why not a compueer? Speaking of which you guys have been had by Steven. That was not an innocent Hello World program. All those who tried it Beware! On the next Friday the 13th when you hear the wings of werewolves waffling inside your disk drive... you know who is responsible [Sound of eerie music] == Merry Christmas everyone! -- https://mail.python.org/mailman/listinfo/python-list
[issue21279] str.translate documentation incomplete
Terry J. Reedy added the comment: I agree with Serhiy: no bullet points, links to glossary (at least in doc), without repeating. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21279 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23098] mknod devices can be 32 bits
Serhiy Storchaka added the comment: This is not so easy as look at first glance. PY_LONG_LONG should be used instead of long long. And as far as this type is optional, its use should be conditional if HAVE_LONG_LONG is defined. May be needed complex converter like _Py_Uid_Converter because dev_t on Linux is 64-bit unsigned int and can not fit in the range of 64-bit signed int. The code for 3.x should be even more complex due to using Argument Clinic. -- components: +Extension Modules nosy: +serhiy.storchaka type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23098 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23099] BytesIO and StringIO values unavailable when closed
New submission from Martin Panter: IOBase.close() doc says file operations raise ValueError, but it is not obvious to me that reading back the “file” buffer is a file operation. with BytesIO() as b: ... b.write(b123) ... 3 b.getvalue() Traceback (most recent call last): File stdin, line 1, in module ValueError: I/O operation on closed file. Even worse, the memoryview gets corrupted on close(): b = BytesIO(b123) m = b.getbuffer() b.close() bytes(m) b'\x98\x02' I also noticed that in the “io” implementation, writing to the file seems to be completely disallowed, even if it would not seem to change the size: b = BytesIO(b123) m = b.getbuffer() b.write(bx) Traceback (most recent call last): File stdin, line 1, in module BufferError: Existing exports of data: object cannot be re-sized -- components: IO messages: 233016 nosy: vadmium priority: normal severity: normal status: open title: BytesIO and StringIO values unavailable when closed type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23099 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19548] 'codecs' module docs improvements
Martin Panter added the comment: Adding patch v2 after learning how to compile the docs and fixing my errors. I also simplified the descriptions of the CodecInfo attributes by defering the constructor signatures to where they are fully defined under “Codec base classes”, and merged the list of error handlers there as well. A side effect of merging error handler lists is that “surrogatepass” is now defined for codecs in general, not just Codec.encode() and decode(). Also I noticed that “unicode_escape” actually does Latin-1 decoding. -- Added file: http://bugs.python.org/file37525/codecs-doc.v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19548 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23099] BytesIO and StringIO values unavailable when closed
Serhiy Storchaka added the comment: getvalue() doesn't work after close() for purpose. close() frees memory used by BytesIO. import io, sys bio = io.BytesIO() sys.getsizeof(bio) 52 bio.write(b'x'*1000) 1000 sys.getsizeof(bio) 1053 bio.close() sys.getsizeof(bio) 52 Changing the behavior will cause regression. The behavior of memoryview looks as a bug. -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23099 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23098] mknod devices can be 32 bits
Jesús Cea Avión added the comment: Serhiy, could you consider to create a patch for 2.7 and 3.4?. I am not familiar with the details of Argument Clinic. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23098 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19548] 'codecs' module docs improvements
Nick Coghlan added the comment: Thanks for those drafts, Martin - they look like a strong improvement to me. While I still had plenty of comments/questions on v2, I think that's more a reflection on how long it has been since we gave these docs a thorough overall review, moreso than a reflection on the proposed changes. Victor - I added you to the nosy list for this one, as I'd specifically like your comments on the StreamReader/Writer docs updates. I'd like to make it clear that these are distinct from the text encoding only APIs in the io module, while still accurately describing the behaviour of the standard codecs. -- nosy: +haypo versions: -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19548 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22939] integer overflow in iterator object
Clement Rouault added the comment: The call to PySequence_GetItem() may be expensive, and we have to drop the result if an OverflowError is raised after the call. You do realize that this error will be very rare and therefore inconsequential. The real question is: why would you call the iterator for a new value if it will be discarded anyway ? I think it could be very misleading to see _getitem__ being called and have an OverflowError being raised afterward. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22939 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23098] mknod devices can be 32 bits
Serhiy Storchaka added the comment: Here is a patch against 3.5. Unsigned bitwise int converter is used for dev_t because dev_t can be unsigned (and it is on Linux). This is not ideal solution, there is no overflow check, but at least it should work for correct code. -- keywords: +patch Added file: http://bugs.python.org/file37526/posix_dev_t_converter-3.5.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23098 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19548] 'codecs' module docs improvements
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19548 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23099] BytesIO and StringIO values unavailable when closed
Antoine Pitrou added the comment: Even worse, the memoryview gets corrupted on close(): The BytesIO object should probably reject closing when a buffer is exported. writing to the file seems to be completely disallowed, even if it would not seem to change the size: An enhancement is probably possible there. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23099 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23096] Implementation-depended pickling floats with protocol 0
Alexandre Vassalotti added the comment: The repr for floats was changed some time ago to use a shorter decimal strings when possible. Both representations should yield the same float value once decoded. If we want to make the C and Python implementations of pickle consistent, then we should pick on what the Python version does currently: i.e., call repr on the float. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23096 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21279] str.translate documentation incomplete
Martin Panter added the comment: The problem with mappings and sequences is that they both require len() and iter() implementations, but str.translate() only requires __getitem__(). Perhaps a qualifier could work, like: The table must implement the __getitem__() method of mappings and sequences. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21279 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23098] mknod devices can be 32 bits
Serhiy Storchaka added the comment: As pointed by Antoine there are other affected functions. Updated patch fixes converting of arguments or results in makedev(), major() and minor(). -- Added file: http://bugs.python.org/file37527/posix_dev_t_converter-3.5_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23098 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23096] Implementation-depended pickling floats with protocol 0
Antoine Pitrou added the comment: This looks less like a bug than an enhancement request. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23096 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23088] Document that PyUnicode_AsUTF8() returns a null-terminated string
Antoine Pitrou added the comment: This looks good to me. -- nosy: +pitrou stage: - commit review type: - behavior versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23088 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22671] Typo in class io.BufferedIOBase docs
Martin Panter added the comment: Adding patch v2 with readinto1() as a “mixin method” and dropped many of my earlier changes for better consistency with the introduction of the classes (which I never really read before :P) -- Added file: http://bugs.python.org/file37528/read-defaults.v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22671 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23100] multiprocessing doc organization impedes understanding
New submission from Davin Potts: The organization and multiple sections of the multiprocessing module's documentation do not adhere to the Python Dev Guidelines for economy of expression, affirmative tone, and/or code examples. Problem description: The raw material and information in the multiprocessing module docs are good to excellent and very information rich -- the presentation of that information suffers primarily from its organization. (1) Too much information is presented in the same or neighboring subsections where the economy of expression guidelines would advocate for a different approach. Specifically, section 17.2.2 Reference co-mingles discourses on usage topics with a description of the available objects and apis. Section 17.2.1 Introduction does something similar and though some of this can be helpful in an intro section, it takes discourse a bit far at times, arguably losing its focus which is to clearly introduce the reader to the module and efficiently set them on a healthy path to understanding topics and establish sufficient comfort to begin working with the module. Economy of expression would have us maintain focus in an Introduction or Reference section and re-organize such helpful discourses into supporting but distinct sections. (2) Affirmative tone is not consistently used throughout the docs. Multiple of the items under section 17.2.3 Programming guidelines leverage negative examples to motivate what should be done instead -- each of these can be rewritten in the way advocated in the Python Dev Guidelines for affirmative tone. (3) Per the Python Dev Guidelines for code examples, examples should accelerate understanding versus alternative prose. Code snippets showcasing internal behavior to the module, such as the Beware of replacing sys.stdin subsection inside 17.2.3.1 All start methods, should arguably have their example code blocks replaced with prose. Section 17.2.4 Examples provides examples showcasing many facets all in the same example code block yet little to no supporting or motivating explanation is offered for each (more could be offered inline as well as outside as prose). Suggested changes: * Re-organize the single multiprocessing module doc into multiple in the style of the logging module. Specifically, tutorials should be created to house the bunny trail discourses from the Introduction/Reference sections and a cookbook should be created to house the material from the Examples section. * By de-bunny-trailing the Introduction/Reference sections, a more focused set of sections in the style of the threading module should result. * Limited modifications to code examples are advocated only so far as they restore the affirmative tone as needed. * New examples are not advocated as part of this issue; they are out-of-scope. This issue is intended to add to the path started/advocated by Issue 22952. It does not supplant but rather expands upon that issue. -- assignee: docs@python components: Documentation messages: 233030 nosy: davin, docs@python, rhettinger priority: normal severity: normal status: open title: multiprocessing doc organization impedes understanding type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23100 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23100] multiprocessing doc organization impedes understanding
Davin Potts added the comment: I am happy to provide proposed patches but first can someone please clarify for me whether I should have those patches depend upon the patches from Issue 22952? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23100 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22952] multiprocessing doc introduction not in affirmative tone
Davin Potts added the comment: Procedural question (wanting to understand the label given to this issue): when documentation does not adhere to the Python Developer's Guide, is a fix for this considered an enhancement? -- versions: +Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22952 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23101] \\di\\\\
Changes by Greg Turner g...@be-evil.net: -- components: Distutils nosy: dstufft, eric.araujo, gmt priority: normal severity: normal status: open title: \\di ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23101 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23101] bleh, sorry, my cat reported this non-bug :)
Changes by Greg Turner g...@be-evil.net: -- status: open - closed title: \\di - bleh, sorry, my cat reported this non-bug :) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23101 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23101] bleh, sorry, my cat reported this non-bug :)
New submission from Éric Araujo: :-) -- resolution: - not a bug stage: - resolved ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23101 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23102] distutils: tip-toe around quirks owing to setuptools monkey-patching Extension
New submission from Greg Turner: Clinical Presentation: Sometimes a developer consuming distutils will write what seems like a perfectly sensible setup.py, but something inscrutable happens: setup.py bombs out claiming error: each element of 'ext_modules' option must be an Extension instance or 2-tuple. Prognosis: Once she manages to capture this error in pdb (takes some doing), intrepid developer may discover that, bizarrely, it IS an Extension instance, yet, somehow, (not isinstance(that_thing, Extension)) == True. Sooner or later she'll likely throw up her hands and follow some far-seeing dude's advice on StackOverflow([1]), which will probably work. If she undertakes a more thorough investigation, she may figure out the true etiology (see below), at which point, various minor tweaks will likely present themselves to her as obvious situation-specific solutions to the problem. Etiology: Developer likely employed code early in her module like: from distutils.extension import Extension . . (some other imports) . setup(..., ext_modules = [ Extension(...), ..., ], ...) What happened was that setuptools got imported by (presumably) some third-party code, at which point, setuptools monkey-patched distutils.extension.Extension(*), as is setuptools' SOP. However, in setup.py, a reference to the un-monkey-patched Extension was already saved off as __main__.Extension (along with, in all probability, other un-patched distutils things, as folks tend to consistently use one style or another of import). So __main__ calls (an un-monkey-patched version of) distutils.core.setup, which ultimately iterates through the list of Extensions, checking isinstance(item, Extension), or so, which, as can now be seen, is not going to be true. So, the error message is correct, it just fails to mention the possibility that there are multiple things called Extension floating around with identical repr's. Epidemiological Outlook: Seemingly this is a rare condition, but when a case develops, it can be costly, due to the likelihood of misdiagnosis and/or partial remission and relapse. One possible vaccine has been developed and is enclosed. It has not been subjected to clinical trial, nor peer-review (until now). It is enclosed as a patch which applies to python 2.7-3.5 and seems to do the trick in the particular case that was buggin' me (wish I could say it will do the trick for any non-broken use-case, but I can't, as if I made such a claim, I'd clearly jinx it). -- * Arguably, this is a bug or misfeature of setuptools, as here setuptools appears to too liberally assume that, if its modules were even casually imported, then it's a good time to monkey-patch distutils. However, IME, fixing this putative bug, threatens to be a non-trivial undertaking and cause a bunch of regressions and contingent hassles. Background URLS: [1] http://stackoverflow.com/questions/21594925/error-each-element-of-ext-modules-option-must-be-an-extension-instance-or-2-t https://bitbucket.org/pypa/setuptools/issue/309 https://bugs.gentoo.org/show_bug.cgi?id=532708 -- components: Distutils files: distutils_accomodate_extension_ducktypes.patch keywords: patch messages: 233034 nosy: dstufft, eric.araujo, gmt priority: normal severity: normal status: open title: distutils: tip-toe around quirks owing to setuptools monkey-patching Extension type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file37529/distutils_accomodate_extension_ducktypes.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23102 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23100] multiprocessing doc organization impedes understanding
Changes by Ned Deily n...@acm.org: -- nosy: +sbt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23100 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19548] 'codecs' module docs improvements
Martin Panter added the comment: New patch version addressing many of the comments; thanks for reviewing! Also adds and extends some unit tests to confirm some of the corner cases I am documenting. -- Added file: http://bugs.python.org/file37530/codecs-doc.v3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19548 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23099] BytesIO and StringIO values unavailable when closed
Serhiy Storchaka added the comment: Here is a patch which rejects close() when a buffer is exported. -- keywords: +patch stage: - patch review versions: +Python 2.7, Python 3.5 Added file: http://bugs.python.org/file37531/bytesio_exported_reject_close.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23099 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
