Re: Code golf challenge: XKCD 936 passwords

[Rob Day]

On 08/10/13 07:17, Chris Angelico wrote:

Who's up for some fun? Implement an XKCD-936-compliant password
generator in Python 3, in less code than this:

print(*__import__("random").sample(open("/usr/share/dict/words").read().split("\n"),4))



print("imploring epsilon decamp graveyard's")
# Chosen by fair random sampling, guaranteed to be random

Comments don't count as code, right? ;)
--
https://mail.python.org/mailman/listinfo/python-list

Re: Strange files??

[Rob Day]

On Wednesday 10 Apr 2013 14:16:23 Joe Hill wrote:
> Recently I installed Python 3.3 successfully.
> 
> Yesterday - I have a bunch of PY files such as thesaurus.py, some *.p7s
> files, some signature files and an index.fpickle.  A total of 23 files.
> 
> Where do they come from and how do they end up as incoming mail???
> Are any of these needed for anything?
> As a rule I sort out or delete all incoming attachments every day.
> j

What do you mean, you have them? Did someone email them to you? If so, surely 
they're nothing to do with installing Python.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Required arguments in argparse: at least one of a group

[Rob Day]

I don't know about argparse, but if you use docopt
(http://docopt.org/) then this is easy to do with something like:

"""Usage:

finder.py --file  --dir 
finder.py --pattern  --dir 
finder.py --file  --pattern  --dir 
"""

On 23 March 2013 16:04, Marco  wrote:
> Is there the possibility using the argparse module to group two or more
> arguments in order to have at least one of them required? For instance, I
> would like to have not an error only in the following cases:
>
>   python finder.py --file myfile --dir mydir
>   python finder.py --pattern mypattern --dir mydir
>   python finder.py --file myfile --pattern mypattern --dir mydir
>
> where --dir is required, and --file _or_ --parser have to be specified. In
> other words, I want the parser prints an error message just in this case:
>
>   python finder.py --dir mydir
>
> Thanks in advance, Marco
> --
> Marco
> --
> http://mail.python.org/mailman/listinfo/python-list



-- 
Robert K. Day
robert@merton.oxon.org
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: need for help

[Rob Day]

It looks like you're using single underscores, not double: the methods
should be __init__ and __str__.

On 1 March 2013 18:35, leonardo selmi  wrote:
> hi guys
>
> i typed the following program:
>
> class ball:
> def _init_(self, color, size, direction):
> self.color = color
> self.size = size
> self.direction = direction
>
> def _str_(self):
> msg = 'hi, i am a ' + self.size + ' ' + self.color + 'ball!'
> return msg
>
> myball = ball('red', 'small', 'down')
> print my ball
>
> BUT I GOT THIS ERROR:
>
> Traceback (most recent call last):
>   File "/Users/leonardo/Documents/ball2.py", line 11, in 
> myball = ball('red', 'small', 'down')
> TypeError: this constructor takes no arguments
>
> can you kindly tell me what is wrong?
> thanks a lot!
> --
> http://mail.python.org/mailman/listinfo/python-list



--
Robert K. Day
robert@merton.oxon.org
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pyrudp

[Rob Day]

Have you seen http://pyraknet.slowchop.com/? It appears to do a similar thing.

On 30 January 2013 17:02, Jorge Alberto Diaz Orozco
 wrote:
> I´ve tried it but it´s not reliable. Datagrams can arive disorganised or just 
> not arive.
> Some programmers said I most use TCP, but I need to use UDP.
> that´s why I need pyrudp, but I can not find it.
>
> On Jan 30, 2013, at 8:12 AM, Jorge Alberto Diaz Orozco
>
> What about the native socket call to SOCK_DGRAM?
>
> Here is a simple example to read messages of a udp socket.
>
> import socket
> UDP_IP = "127.0.0.1"
> UDP_PORT = 5005
>
> sock = socket.socket(socket.AF_INET, # Internet
> socket.SOCK_DGRAM) # UDP
> sock.bind((UDP_IP, UDP_PORT))
>
> while True:
> data, addr = sock.recvfrom(1024) # buffer size is 1024 bytes
> print "received message:", data
> --
> http://mail.python.org/mailman/listinfo/python-list



-- 
Robert K. Day
robert@merton.oxon.org
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: WLAN tester

[Rob Day]

On 28 January 2013 17:07, Wanderer  wrote:
> Yes. I noticed this variability. I've been using the Totusoft 
> Lan_Speedtest.exe to test some modules. I've tested through the wifi to our 
> intranet and saw variations I believe do to network traffic. I also tried 
> peer to peer and the write time actual got worse. I don't know if it has do 
> to with the firewall or the hard drive speed or just Windows giving this 
> process low priority. I also saw drop outs. So figuring out the metric for 
> pass/fail will be interesting. I'll check into setting an ftp for this test.

Why involve a protocol at all? I'd just create a socket
(http://docs.python.org/3.3/library/socket.html) and measure how long,
on average, it took to write a given number of arbitrary bytes (e.g.
"This is a string" repeated a million times) to it and then read a
given number of bytes back. That would be a relatively consistent
metric, whereas if you try using FTP you'll run into issues, as
already noted, where disk read/write speed and details of your FTP
server implementation like compression or multiple network connections
affect the result significantly.

--
Robert K. Day
robert@merton.oxon.org
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Dict comp help

[Rob Day]

On 24 January 2013 21:11, Oscar Benjamin  wrote:
 l = [{'a': 'xx', 'b': 'yy', 'c': 'zz'}, {'a': 'dd', 'b': 'ee', 'c': 'ff'}]
 dict(d.values()[:2] for d in l)
> {'xx': 'zz', 'dd': 'ff'}

Python doesn't guarantee any ordering of items in a dictionary; {'a':
'xx', 'b': 'yy', 'c': 'zz'}.values()[:2] may not return ['xx', 'zz']
in different Python implementations or future versions (though it
seems to work consistently in CPython 2.7). See
http://docs.python.org/2/library/stdtypes.html#dict.items.

--
Robert K. Day
robert@merton.oxon.org
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: sqlite3 puzzle

[Rob Day]

Glad I could help!


Using a local source control system like git, bzr or hg is really
useful in situations like these - it's far, far easier to debug issues
of the form "I made changes and now it's broken" when you can do `git
diff yesterday's-version today's-version` and see exactly what the
changes were.


On 15 January 2013 20:29, llanitedave  wrote:
> On Tuesday, January 15, 2013 9:13:13 AM UTC-8, Rob Day wrote:
>> On 15 January 2013 15:51, llanitedave  wrote:
>>
>> > Thanks for the suggestion, Rob, but that didn't make any difference.  I've 
>> > never had an issue with putting the execute object into a variable and 
>> > calling "fetch" on that variable.
>>
>> >
>>
>> > I can accept reality if it turns out that foreign keys simply isn't 
>> > enabled on the Python distribution of sqlite, although I don't know why 
>> > that should be the case.  I'm just curious as to why it worked at first 
>> > and then stopped working.
>>
>>
>>
>> Well - you might be able to accept that, but I'm not sure I can! If it
>>
>> was working before, it must be compiled in, and so it must be possible
>>
>> to make it work again.
>>
>>
>>
>> http://www.sqlite.org/foreignkeys.html#fk_enable seems to suggest that
>>
>> "PRAGMA foreign_keys = ON" never returns anything, and it's only
>>
>> "PRAGMA foreign_keys" which returns 0, 1 or None (when unsupported).
>>
>> With that in mind, does the following code work?
>>
>>
>>
>> # open database file
>>
>>
>>
>> self.geologger_db = sqlite3.connect('geologger.mgc')
>>
>> self.db_cursor = self.geologger_db.cursor()
>>
>> self.db_cursor.execute("PRAGMA foreign_keys = ON")
>>
>> self.db_cursor.execute("PRAGMA foreign_keys")
>>
>> print self.db_cursor.fetchone()
>
> "http://www.sqlite.org/foreignkeys.html#fk_enable seems to suggest that 
> "PRAGMA foreign_keys = ON" never returns anything, and it's only "PRAGMA 
> foreign_keys" which returns 0, 1 or None (when unsupported)."
>
> That was it, exactly, Rob.  I don't know where I got the idea that I was 
> getting  a '1' from the 'ON' command, although I was sure that I'd seen it.  
> But once I just called "foreign_key" it returned just fine.
>
> Ummm...  Obviously I was up fiddling around too late.  Yeah, that's it.
>
>
> Thanks!  It's solved now.
> --
> http://mail.python.org/mailman/listinfo/python-list



-- 
Robert K. Day
robert@merton.oxon.org
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: sqlite3 puzzle

[Rob Day]

On 15 January 2013 15:51, llanitedave  wrote:
> Thanks for the suggestion, Rob, but that didn't make any difference.  I've 
> never had an issue with putting the execute object into a variable and 
> calling "fetch" on that variable.
>
> I can accept reality if it turns out that foreign keys simply isn't enabled 
> on the Python distribution of sqlite, although I don't know why that should 
> be the case.  I'm just curious as to why it worked at first and then stopped 
> working.

Well - you might be able to accept that, but I'm not sure I can! If it
was working before, it must be compiled in, and so it must be possible
to make it work again.

http://www.sqlite.org/foreignkeys.html#fk_enable seems to suggest that
"PRAGMA foreign_keys = ON" never returns anything, and it's only
"PRAGMA foreign_keys" which returns 0, 1 or None (when unsupported).
With that in mind, does the following code work?

# open database file

self.geologger_db = sqlite3.connect('geologger.mgc')
self.db_cursor = self.geologger_db.cursor()
self.db_cursor.execute("PRAGMA foreign_keys = ON")
self.db_cursor.execute("PRAGMA foreign_keys")
print self.db_cursor.fetchone()
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: sqlite3 puzzle

[Rob Day]

On 15 January 2013 07:09, llanitedave  wrote:

> So I put the following test code in my initialization method:
>
> # open database file
> self.geologger_db = sqlite3.connect('geologger.mgc')
> self.db_cursor = self.geologger_db.cursor()
> self.foreign_key_status = self.db_cursor.execute("PRAGMA foreign_keys = 
> ON")
> self.foreign_key_status = self.foreign_key_status.fetchone()
>
> print self.foreign_key_status
>
> I ran this several times while I was arranging the downstream queries, and 
> each time it returned '(1,)', which means foreign keys is enabled.
>
> But I was using a variable named 'cmd1' as a placeholder until I changed the 
> name to
> the more descriptive 'self.foreign_key_status'.  Since I made the name 
> change, however,
> the code only returns 'None'.  Reverting to the previous variable name has no 
> effect.

Hmm - your code doesn't quite match up with the docs at
http://docs.python.org/2/library/sqlite3.html. That seems to suggest
that you should call fetchone() on the cursor, not on the result of
execute().

Does the following work?

# open database file
self.geologger_db = sqlite3.connect('geologger.mgc')
self.db_cursor = self.geologger_db.cursor()
self.db_cursor.execute("PRAGMA foreign_keys = ON")
print self.db_cursor.fetchone()


--
Robert K. Day
robert@merton.oxon.org
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Unittest - testing for filenames and filesize

[Rob Day]

On Sun, 2012-08-26 at 10:36 -0700, Tigerstyle wrote:
> self.assertEqual(statinfo.st_size, filesize)
> 
> I'm still getting AssertionError and the error says: 100 !=b'
> 
> 

filesize is the character 'b' repeated one million times (the contents
of the file, in other words). statinfo.st_size is the number of bytes in
the file, i.e. 1,000,000. So when your assertEqual code checks if those
two values are equal, what do you think happens?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: help with simple print statement!

[Rob Day]

On Fri, 2012-08-24 at 12:43 -0700, Willem Krayenhoff wrote:
> Any idea why print isn't working here?  

You're using Python 3.2, but trying Python 2.7 syntax -
http://docs.python.org/release/3.0.1/whatsnew/3.0.html#print-is-a-function 
should explain the problem adequately.

(Incidentally - you can copy from the Windows console by right-clicking
and selecting "Mark". It's a little easier than taking a screenshot!)

Rob




-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [CGI] Why is HTML not rendered?

[Rob Day]

On 17 August 2012 14:27, Gilles  wrote:

>
> print "Content-Type: text/plain;charset=utf-8"
> print
>


Here's the problem - you're telling the browser to display in plain text.
Try 'text/html' instead.

-- 
Robert K. Day
robert@merton.oxon.org
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to call perl script from html using python

[Rob Day]

On 16 August 2012 08:23, Pervez Mulla  wrote:

>
>
> In HTml when user submit POST method, it calling Python code Instead
> of this I wanna call perl script for sign up ..
>
>
Can you not just change the action= attribute in your  HTML attribute
to point to your Perl CGI script?

-- 
Robert K. Day
robert@merton.oxon.org
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A difficulty with lists

[Rob Day]

> The list nlist inside of function xx is not the same as the variable u
> outside of the function:  nlist and u refer to two separate list objects.
>  When you modify nlist, you are not modifying u.
> 


Well - that's not quite true. Before calling the function, u is [1, 2, 3,
4] - but after calling the function,  u is [1, 2, 3, 4, 999]. This is a
result of using 'nlist += [999]' - the same thing doesn't happen if you use
'nlist = nlist+[999]' instead.

I'm not completely aware of what's going on behind the scenes here, but I
think the problem is that 'nlist' is actually a reference to a list object
- it points to the same place as u. When you assign to it within the
function, then it becomes separate from u - which is why nlist =
nlist+[999] and nlist = nlist[:-1] don't modify u - but if you modify nlist
in place before doing that, such as by using +=, then it's still pointing
to u, and so u gets modified as well.

So, for example:

>>> def blank_list(nlist):
... nlist[:] = [] # modifies the list in-place
...
>>> u
[1, 2, 3, 4]
>>> blank_list(u)
>>> u
[] # u has been changed by our change to nlist!

But if we change it so that it assigns to nlist rather than modifying it:

>>> def dont_blank_list(nlist):
... nlist = [] # creates a new list object rather than modifying the
current one
...
>>> u = [1, 2, 3, 4]
>>> u
[1, 2, 3, 4]
>>> dont_blank_list(u)
>>> u
[1, 2, 3, 4] # u is completely unaffected!
-- 
Robert K. Day
robert@merton.oxon.org




-- 
Robert K. Day
robert@merton.oxon.org
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Sharing code between different projects?

[Rob Day]

I'd just create a module - called shared_utils.py or similar - and import
that in both projects. It might be a bit messy if there's no 'unifying
theme' to the module - but surely it'd be a lot less messy than your
TempDirectory class, and anyone else who knows Python will understand
'import shared_utils' much more easily.

I realise you might not want to say, but if you could give some idea what
sort of projects these are, and what sorts of code you're trying to share,
it might make things a bit clearer.

I'm not really sure what your concerns about 'versioning and how to link
different pieces together' are - what d you think could go wrong here?

On 13 August 2012 17:53, andrea crotti  wrote:

> I am in the situation where I am working on different projects that
> might potentially share a lot of code.
>
> I started to work on project A, then switched completely to project B
> and in the transiction I copied over a lot of code with the
> corresponding tests, and I started to modify it.
>
> Now it's time to work again on project A, but I don't want to copy
> things over again.
>
> I would like to design a simple and nice way to share between projects,
> where the things I want to share are simple but useful things as for
> example:
>
> class TempDirectory:
> """Create a temporary directory and cd to it on enter, cd back to
> the original position and remove it on exit
> """
> def __init__(self):
> self.oldcwd = getcwd()
> self.temp_dir = mkdtemp()
>
> def __enter__(self):
> logger.debug("create and move to temp directory %s" %
> self.temp_dir)
> return self.temp_dir
>
> def __exit__(self, type, value, traceback):
> # I first have to move out
> chdir(self.oldcwd)
> logger.debug("removing the temporary directory and go back to
> the original position %s" % self.temp_dir)
> rmtree(self.temp_dir)
>
>
> The problem is that there are functions/classes from many domains, so it
> would not make much sense to create a real project, and the only name I
> could give might be "utils or utilities"..
>
> In plus the moment the code is shared I must take care of versioning and
> how to link different pieces together (we use perforce by the way).
>
> If then someone else except me will want to use these functions then of
> course I'll have to be extra careful, designing really good API's and so
> on, so I'm wondering where I should set the trade-off between ability to
> share and burden to maintain..
>
> Anyone has suggestions/real world experiences about this?
> --
> http://mail.python.org/mailman/listinfo/python-list
>



-- 
Robert K. Day
robert@merton.oxon.org
-- 
http://mail.python.org/mailman/listinfo/python-list