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)
>>> 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 "", line 1, in
>>> d
Traceback (most recent call last):
File "", line 1, in
>>> quit()
Traceback (most recent call last):
File "", line 1, in
Thanks in advance.
Best regards,
Shawool
--
https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
Chris Angelico : > 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)
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 "", line 1, in
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 "", line 1, in
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 wrote: > Chris Angelico : > >> 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 "", 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 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 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)
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 "", line 1, in
d
Traceback (most recent call last):
File "", line 1, in
quit()
Traceback (most recent call last):
File "", line 1, in
Like all of these things.
--
Ned Batchelder, http://nedbatchelder.com
--
https://mail.python.org/mailman/listinfo/python-list
Re: List Comprehensions
In article , Chris Angelico wrote: > On Mon, Dec 22, 2014 at 4:42 PM, Ganesh Pal 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 wrote: > On Mon, 22 Dec 2014 09:51:02 +1100, Steven D'Aprano > 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 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 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 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 : > 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 wrote: > Roy Smith : > > > 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 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 > 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 "", line 1, in > 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
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 = u"rm ――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
Re: Hello World
On 2014-12-21, 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. 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 wrote: > In article <54974ed7$0$12986$c3e8da3$54964...@news.astraweb.com>, > Steven D'Aprano 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 wrote: > On Mon, 22 Dec 2014 09:51:02 +1100, Steven > D'Aprano> 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 "", line 1, in 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 wrote: > Chris Angelico wrote: > >> On Mon, Dec 22, 2014 at 8:21 PM, Steven D'Aprano >> 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 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 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)
>
> >>> 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 "", line 1, in
> >>> d
> Traceback (most recent call last):
> File "", line 1, in
> >>> quit()
> Traceback (most recent call last):
> File "", line 1, in
>
>
> 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
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 wrote: In article <54974ed7$0$12986$c3e8da3$54964...@news.astraweb.com>, Steven D'Aprano 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 wrote: In article <54974ed7$0$12986$c3e8da3$54964...@news.astraweb.com>, Steven D'Aprano 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 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 Luke Tomaneng 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 wrote: Chris Angelico wrote: On Mon, Dec 22, 2014 at 8:21 PM, Steven D'Aprano 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 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 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 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. 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, 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" 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" 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" 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 998 999 Traceback (most recent call last): File "", line 1, in File "", line 3, in test File "", line 3, in test File "", line 3, in test File "", line 3, in test File "", 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, 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 , Tim Chase 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 wrote: > In article , > Tim Chase 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 , > Tim Chase 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 , Tim Chase 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 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 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 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
