pycurl.error: (55, 'select/poll returned error')
When calling curl.perform() on a curl instance I get this: pycurl.error: (55, 'select/poll returned error') On the server side, there is no error message at all. I suppose that the curl client tries to call select/poll on the socket. It fails and then returns with an error. This error happens only if the file to be POST-ed is big enough. Last week files were under 1GB and everything went fine. Files above about 1GB cannot be sent over with curl. I have found some threads on the net about this bug, but I couldn't find any solution. Python version: Python 3.4.3 (default, Mar 5 2015, 22:48:48) [GCC 4.2.1 Compatible FreeBSD Clang 3.4.1 (tags/RELEASE_34/dot1-final 208032)] on freebsd10 Curl version: 'PycURL/7.19.5.1 libcurl/7.41.0 OpenSSL/1.0.1j zlib/1.2.8' I need to use this program to backup files. The backup program itself has lots of code tied to pycurl so it would be difficult to change to a different library. Thanks Laszlo -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- https://mail.python.org/mailman/listinfo/python-list
Re: test1
Am 26.03.15 um 02:34 schrieb Tiglath Suriol: I may stay a while just to poke you in the eye a little longer. I am beginning to enjoy this. People entering a battle of wits unarmed. It's a joy to watch. Wow you must be really bored. Christian -- https://mail.python.org/mailman/listinfo/python-list
Re: module attributes and docstrings
On Thu, 26 Mar 2015 08:48 pm, Mario Figueiredo wrote: > Sorry for the late reply. We experienced a 3 day blackout following > one of the most amazing thunderstorms I've witnessed in my life. Wow. Where abouts are you? Apart from the blackout, did you get through it alright? More below... > On Tue, 24 Mar 2015 22:49:49 +1100, Steven D'Aprano > wrote: [...] >>Even if there was support from the compiler to extract the docstring, >>where would it be stored? Consider: >> >>spam = None >>"""Spammy goodness.""" >>eggs = None >>"""Scrambled, not fried.""" >> >>There's only one None object, and even if it could take a docstring (and >>it can't), which docstring would it get? Presumably the second, which >>would make help(spam) confusing, but when we say eggs = 23 the docstring >>would disappear too. > > This is a byproduct of me still thinking in terms of C variables. When > I first read that paragraph of yours, it didn't make sense to me -- > "What is he talking about? I'm documenting the spam and eggs > identifiers, not the None object". > > But when I was trying to reply to you by mounting a case around > writing directly to the __doc__ attribute of the spam and eggs > identifiers, the python shell was quick to make me realized my > foolishness, and I remembered about Python variables not being the > same as C variables. Yes, that's exactly it! Some people prefer to say "Python has no variables, it has name bindings". I think that it's better to say that Python's variables are not *like* C or Pascal variables, rather than invent a distinction between name bindings and variables. Name bindings are a type of variable. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: module attributes and docstrings
Steven D'Aprano : > Some people prefer to say "Python has no variables, it has name > bindings". I think that it's better to say that Python's variables are > not *like* C or Pascal variables, rather than invent a distinction > between name bindings and variables. Name bindings are a type of > variable. I guess the thinking goes like this: In Python, everything is a first-class object. In Python, variables are not first-class objects. Ergo: In Python, there are no variables. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: What is elegant way to do configuration on server app
Hi Grant: Why use SIGHUP, Does it has something to do with configure file modification? I don't get it. Thank you. On Thu, Mar 26, 2015 at 11:49 PM, Grant Edwards wrote: > On 2015-03-26, Ben Finney wrote: >> Jerry OELoo writes: >> >>> Currently, I can just think out that I put status into a configure >>> file, and service schedule read this file and get status value, >> >> That sounds like a fine start. Some advice: >> >> * You may be tempted to make the configuration file executable (e.g. >> Python code). Resist that temptation; keep it *much* simpler, a >> non-executable data format. >> >> Python's standard library has the ‘configparser’ module >> https://docs.python.org/3/library/configparser.html> to parse and >> provide the values from a very common configuration file format. >> Use that unless you have a good reason not to. > > I second the recommendation for configparser for stuff of simple to > moderate complexity. If it gets too complex for configparser, you may > want to consider JSON, or for even more complex stuff just use plain > Python code in your config file (this can be very powerful and > expressive, but can also be diffucult to implement safely). > >> * Your program can “poll” the configuration file to see whether it has >> changed. At startup, read the config file's modification timestamp >> https://docs.python.org/3/library/os.html#os.stat_result.st_mtime>. >> >> Make a part of your event loop (assuming your server runs an event >> loop) that wakes up every N seconds (e.g. every 60 seconds) and >> checkes the file's modification timestamp again; if it's newer, record >> that value for future comparisons, then re-read the file for its >> values. > > That sounds rather Windowsesque. The more-or-less standard way to do > handle the situation on Unix is to reread the config file when you get > a SIGHUP. > > -- > Grant Edwards grant.b.edwardsYow! ONE LIFE TO LIVE for > at ALL MY CHILDREN in ANOTHER > gmail.comWORLD all THE DAYS OF >OUR LIVES. > -- > https://mail.python.org/mailman/listinfo/python-list -- Rejoice,I Desire! -- https://mail.python.org/mailman/listinfo/python-list
asyncio
Hi,
I wrote simple asyncio program (see below) and I'm not sure if I understand
behavior correctly.
I have print_tasks coroutine which prints each task in a loop by using
Task.all_tasks function.
I have also task_launcher coroutine that launches (by loop.create_task())
simple task that waits some and prints "ping".
Question is why finished "ping" tasks keep accumulating in Task.all_tasks?
After a while there is a lot of:
result=None>
when printing in Task.all_tasks and number of those increases as new ping
tasks are launched
Is there a way to prune finished tasks (I tried forcing gc) or I do
something wrong?
I ran on python 3.4.3.
Best regards,
L
import asyncio
loop = asyncio.get_event_loop()
@asyncio.coroutine
def print_tasks(loop):
while True:
tasks = asyncio.Task.all_tasks(loop)
for task in tasks:
print(task)
print()
yield from asyncio.sleep(1)
@asyncio.coroutine
def task_launcher(loop):
while True:
yield from asyncio.sleep(1)
loop.create_task(ping())
@asyncio.coroutine
def ping():
yield from asyncio.sleep(2)
print("ping")
loop.create_task(print_tasks(loop))
loop.create_task(task_launcher(loop))
loop.run_forever()
--
https://mail.python.org/mailman/listinfo/python-list
Re: Sudoku solver
"Marko Rauhamaa" wrote in message news:[email protected]... > "Frank Millman" : > >> Here is another python-based sudoku solver - >> >> http://www.ics.uci.edu/~eppstein/PADS/Sudoku.py >> >>>From its docstring - >> >> "A proper Sudoku puzzle must have a unique solution, and it should be >> possible to reach that solution by a sequence of logical deductions >> without trial and error. > > I don't think that statement holds water. Trial-and-error is at the > basis of deduction (reductio ad absurdum). The human solver employs it > in their head. The question is, what is the difference between > pen-and-paper and in-your-head for a computer program? > [...] >> >> It solved Marko's original puzzle and Ian's puzzle in less than a >> second. It could not solve Marko's second one, returning "impossible" >> immediately. > > ... but that realization greatly reduces the value of the solver. > I was not happy with that conclusion, but I was not sure why. Now I think I can put it into words. There seems to be disagreement over the use of the term 'trial and error'. How about this for a revised wording - "It should be possible to reach that solution by a sequence of logical deductions. Each step in the sequence must uniquely identify the contents of at least one cell based on the information available. Each time a cell is identified, that adds to the information available which can then be used to identify the contents of further cells. This process continues until the contents of all cells have been identified." Any puzzle that cannot be solved by this method does not qualify as a true Sudoku puzzle. Frank -- https://mail.python.org/mailman/listinfo/python-list
Re: What is elegant way to do configuration on server app
On Fri, Mar 27, 2015 at 7:28 PM, Jerry OELoo wrote: > Hi Grant: > Why use SIGHUP, Does it has something to do with configure file > modification? I don't get it. Thank you. Long tradition. I have no idea why that particular signal is used, but it's a well-known convention. In any case, it's certainly sensible to use a signal; it's an easy way for one process to notify another, without needing much overhead or anything. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Sudoku solver
On Fri, Mar 27, 2015 at 8:07 PM, Frank Millman wrote: > There seems to be disagreement over the use of the term 'trial and error'. > How about this for a revised wording - > > "It should be possible to reach that solution by a sequence of logical > deductions. Each step in the sequence must uniquely identify the contents of > at least one cell based on the information available. Each time a cell is > identified, that adds to the information available which can then be used to > identify the contents of further cells. This process continues until the > contents of all cells have been identified." > > Any puzzle that cannot be solved by this method does not qualify as a true > Sudoku puzzle. That's reasonable wording. Another way to differentiate between the "trial and error" that we're objecting to and the "logical deduction" that we're liking: Avoid backtracking. That is, you never guess a number and see if the puzzle's solvable, and backtrack if it isn't; at every step, the deductions you make are absolute certainties. They might, in some cases, not result in actual result numbers (you might deduce that "either this cell or that cell is a 2"), but it's a certainty, based solely on the clue numbers given. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Cannot Uninstall 3.4
On 26/03/2015 23:52, T Younger wrote: > I have 3.4.1 (8/14) and replaced it with 3.4.2 (12/14) > Neither of these uninstalled or I do not believe even had the option. > > I now wanted to update to 3.4.3 and the uninstall fails, provided the > message that the installer is missing a program then backs off the changes. (Assuming Windows since you speak of an "installer" which wouldn't be typical on Unix). If your only goal is to upgrade, then you should be able to do that without uninstalling. Simply download the 3.4.3 installer and install over the 3.4.2 installation. If you do want to uninstall for any other reason, sometimes the best thing is to download the original installer, run it, and select the "Remove All" option (or whatever it's called). TJG -- https://mail.python.org/mailman/listinfo/python-list
ctypes problem: segfault with pointer usage
Hi,
I have a segfault problem with ctypes. Script attached.
I simply need to call `libgio.g_file_new_for_path` and then
`libgio.g_file_get_uri` with its result. That result is a GFile*. Since I
don't manipulate that GFile* I don't think I have to mess with argtypes &
restype of the functions. I still tried ctypes.c_uint and ctypes.c_void_p.
In all cases after a few iterations g_file_get_uri will segfault. This does
not happen in the native version.
You will find python & c script attached.
Here is the result of a typical run:
$ LANG=C python2 ctypes_gio.py
Step 0
getting g_file_ptr for /foo/bar
getting uri_ptr with 8093280
free g_file_ptr
getting uri
free uri_ptr
Step 1
getting g_file_ptr for /foo/bar
getting uri_ptr with 8093344
free g_file_ptr
getting uri
free uri_ptr
Step 2
getting g_file_ptr for /foo/bar
getting uri_ptr with 8093824
free g_file_ptr
getting uri
free uri_ptr
Step 3
getting g_file_ptr for /foo/bar
getting uri_ptr with 8093440
free g_file_ptr
getting uri
free uri_ptr
Step 4
getting g_file_ptr for /foo/bar
getting uri_ptr with 8093472
free g_file_ptr
getting uri
free uri_ptr
Step 5
getting g_file_ptr for /foo/bar
getting uri_ptr with 8093856
free g_file_ptr
getting uri
free uri_ptr
Step 6
getting g_file_ptr for /foo/bar
getting uri_ptr with 140176928020160
free g_file_ptr
Erreur de segmentation (core dumped)
As you can see segfault happens as soon as the pointer position is outside
[0, 2^31[.
This is why I tried messing with argument/response types.
What am I doing wrong? Any pointer (ahah) on how to solve my problem?
The c code can be compiled that way:
$ gcc $(pkg-config --cflags gio-2.0) segfault.c -o segfault $(pkg-config
--libs gio-2.0)
Thanks
Bruno
import ctypes
import ctypes.util
class GioURI(object):
"""Use gio URI function g_file_get_uri. Paths must be utf-8 encoded.
"""
name = "GIO"
def __init__(self):
self.libgio = self.get_library()
self.available = bool(self.libgio)
def get_library(self):
lib_name = ctypes.util.find_library("gio-2")
try:
return ctypes.cdll.LoadLibrary(lib_name)
except OSError:
return False
def uri(self, path):
print(b"getting g_file_ptr for %s" % path)
self.libgio.g_file_new_for_path.restype = ctypes.c_void_p
g_file_ptr = self.libgio.g_file_new_for_path(path)
if not g_file_ptr:
raise RuntimeError("No gfile pointer received for {0!r}".format(
path))
try:
print("getting uri_ptr with %s" % g_file_ptr)
uri_ptr = self.libgio.g_file_get_uri.argtypes = [ctypes.c_void_p]
uri_ptr = self.libgio.g_file_get_uri(g_file_ptr)
except:
print("got exception")
raise
finally:
print("free g_file_ptr")
self.libgio.g_object_unref(g_file_ptr)
if not uri_ptr:
print("free uri_ptr")
self.libgio.g_free(uri_ptr)
raise RuntimeError("No URI received from the gfile pointer for "
"{0!r}".format(path))
try:
print("getting uri")
uri = ctypes.c_char_p(uri_ptr).value
except:
print("got exception")
raise
finally:
print("free uri_ptr")
self.libgio.g_free(uri_ptr)
return uri
def test():
gio = GioURI()
if not gio.available:
print("no gio")
return
for i in range(10):
print("Step %s" % i)
gio.uri(b"/foo/bar")
if __name__ == '__main__':
test()
#include
#include
int main() {
int i;
GFile* f;
const char* path = "/foo/bar";
char* uri;
for(i = 0; i < 100; i++) {
f = g_file_new_for_path(path);
printf("%i ", f);
uri = g_file_get_uri(f);
g_object_unref(f);
printf("%s\n", uri);
}
return 0;
}
--
https://mail.python.org/mailman/listinfo/python-list
Re: Supply condition in function call
On 03/26/2015 09:41 PM, Rustom Mody wrote: On Thursday, March 26, 2015 at 11:30:57 AM UTC+5:30, Chris Angelico wrote: Python 3.5.0a0 (default:4709290253e3, Jan 20 2015, 21:48:07) [GCC 4.7.2] on linux class filter(object) | filter(function or None, iterable) --> filter object | | Return an iterator yielding those items of iterable for which function(item) | is true. If function is None, return the items that are true. | | Methods defined here: ... On a more specific note, its the 1st line: class filter(object) which knocks me off. If a more restricted type from the ABC was shown which exactly captures all the iterator-specific stuff like __iter__, __next__ it would sure help (me) Since it's not actually derived from anything else, I'd leave that part alone. But it could be useful to add something like: ducktype: collections.abc.Iterable if nothing else, it'd get beginners to the language to start thinking more of what duck typing is, in Python. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: What is elegant way to do configuration on server app
Grant Edwards : > That sounds rather Windowsesque. The more-or-less standard way to do > handle the situation on Unix is to reread the config file when you get > a SIGHUP. That, indeed, is the classic Unix way. However, Linux has now moved to systemd: ExecReload= Commands to execute to trigger a configuration reload in the service. This argument takes multiple command lines, following the same scheme as described for ExecStart= above. Use of this setting is optional. Specifier and environment variable substitution is supported here following the same scheme as for ExecStart=. One additional, special environment variable is set: if known, $MAINPID is set to the main process of the daemon, and may be used for command lines like the following: /bin/kill -HUP $MAINPID Note however that reloading a daemon by sending a signal (as with the example line above) is usually not a good choice, because this is an asynchronous operation and hence not suitable to order reloads of multiple services against each other. It is strongly recommended to set ExecReload= to a command that not only triggers a configuration reload of the daemon, but also synchronously waits for it to complete. http://www.freedesktop.org/software/systemd/ma n/systemd.service.html> Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: asyncio
Hi, On Friday, March 27, 2015 at 1:55:36 AM UTC-7, Marko Rauhamaa wrote: > Łukasz Ligowski : > > > Is there a way to prune finished tasks (I tried forcing gc) or I do > > something wrong? > > Guessing that you need to call asyncio.wait() or asyncio.wait_for() to > get rid of the zombies. > > (Apparently the loop object keeps references to completed tasks. I'm not > sure this design choice is necessary.) Should I launch tasks differently? Waiting for task that is done returns that task in done subset but it still lingers in list of all tasks... Best regards, L -- https://mail.python.org/mailman/listinfo/python-list
Re: asyncio
[email protected]: > On Friday, March 27, 2015 at 1:55:36 AM UTC-7, Marko Rauhamaa wrote: >> Łukasz Ligowski : >> >> > Is there a way to prune finished tasks (I tried forcing gc) or I do >> > something wrong? >> >> Guessing that you need to call asyncio.wait() or asyncio.wait_for() to >> get rid of the zombies. >> >> (Apparently the loop object keeps references to completed tasks. I'm not >> sure this design choice is necessary.) > > Should I launch tasks differently? Waiting for task that is done returns > that task in done subset but it still lingers in list of all tasks... I don't know the answer to your question. A superficial glance at the relevant asyncio source code (and documentation) suggests you shouldn't be seeing what you are seeing. Tasks are kept in a weak set. Tasks should evaporate as soon as nobody references them. I wonder if there's a cyclical reference there somewhere. See if running GC removes the tasks. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: asyncio
Łukasz Ligowski : > Is there a way to prune finished tasks (I tried forcing gc) or I do > something wrong? Guessing that you need to call asyncio.wait() or asyncio.wait_for() to get rid of the zombies. (Apparently the loop object keeps references to completed tasks. I'm not sure this design choice is necessary.) Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: test1
On Friday, March 27, 2015 at 3:33:37 AM UTC-4, Christian Gollwitzer wrote: > Am 26.03.15 um 02:34 schrieb Tiglath Suriol: > > I may stay a while just to poke you in the eye a little longer. I am > > beginning to enjoy this. People entering a battle of wits unarmed. > > It's a joy to watch. > > Wow you must be really bored. > > Christian If I were, you guys keep trying to help me. Atheist -- https://mail.python.org/mailman/listinfo/python-list
Re: What is elegant way to do configuration on server app
On Fri, Mar 27, 2015 at 7:47 PM, Marko Rauhamaa wrote: > Grant Edwards : > >> That sounds rather Windowsesque. The more-or-less standard way to do >> handle the situation on Unix is to reread the config file when you get >> a SIGHUP. > > That, indeed, is the classic Unix way. However, Linux has now moved to > systemd: > >Note however that reloading a daemon by sending a signal (as with >the example line above) is usually not a good choice, because >this is an asynchronous operation and hence not suitable to order >reloads of multiple services against each other. It is strongly >recommended to set ExecReload= to a command that not only >triggers a configuration reload of the daemon, but also >synchronously waits for it to complete. The number of cases where this matters is fairly low. Doing the reload asynchronously is generally sufficient. And even if you have something that waits for the reload to finish, you'll usually fire-and-forget that command anyway. For maximum portability, most programs are going to want to continue to respond to SIGHUP, even if they do a systemd-triggered reload some other way. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: test1
Well, quiet at last. I think. I expected people in a comp.lang group to have been to college but you guys are barely literate. And if you've been to college it must be true we have an education crisis. Dumb comments, schoolyard insults, and fecal references is all you had to offer. Except for the one polite exception, the rest kept at the level of a street ruffian. If you've been this quiet to start with, the soft tissue in your derriere would not be so red. Live and learn. Stay put now, don't make me come back. -- https://mail.python.org/mailman/listinfo/python-list
Re: Sudoku solver
On 03/27/2015 05:25 AM, Chris Angelico wrote: On Fri, Mar 27, 2015 at 8:07 PM, Frank Millman wrote: There seems to be disagreement over the use of the term 'trial and error'. How about this for a revised wording - "It should be possible to reach that solution by a sequence of logical deductions. Each step in the sequence must uniquely identify the contents of at least one cell based on the information available. Each time a cell is identified, that adds to the information available which can then be used to identify the contents of further cells. This process continues until the contents of all cells have been identified." Any puzzle that cannot be solved by this method does not qualify as a true Sudoku puzzle. That's reasonable wording. Another way to differentiate between the "trial and error" that we're objecting to and the "logical deduction" that we're liking: Avoid backtracking. That is, you never guess a number and see if the puzzle's solvable, and backtrack if it isn't; at every step, the deductions you make are absolute certainties. They might, in some cases, not result in actual result numbers (you might deduce that "either this cell or that cell is a 2"), but it's a certainty, based solely on the clue numbers given. I like that wording. It fits what I meant by trial and error. Frank: But now I have to disagree about "true Sudoku puzzle." As we said earlier, it might make sense to say that puzzles that cannot be solved that way are not reasonable ones to put in a human Sudoku book. But why isn't it a "true Sudoku puzzle"? Isn't the fact that one resorts to trial and error simply a consequence of the fact that he/she has run out of ideas for more direct rules and the data structures to support them? The simpler rules can be built around a list of possible values for each cell. More complex rules can have a more complex data structure for each cell/row/column/box. And when you run out of ideas for all those, you use guess and backtrack, where the entire board's state is your data structure. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: ctypes problem: segfault with pointer usage
Found the problem: I just have to add libgio.g_object_unref.argtypes = [ctypes.c_void_p] It now works flawlessly! Sorry for the noise. 2015-03-27 13:03 GMT+01:00 Bruno Cauet : > Hi, > I have a segfault problem with ctypes. Script attached. > I simply need to call `libgio.g_file_new_for_path` and then > `libgio.g_file_get_uri` with its result. That result is a GFile*. Since I > don't manipulate that GFile* I don't think I have to mess with argtypes & > restype of the functions. I still tried ctypes.c_uint and ctypes.c_void_p. > In all cases after a few iterations g_file_get_uri will segfault. This does > not happen in the native version. > You will find python & c script attached. > > Here is the result of a typical run: > > $ LANG=C python2 ctypes_gio.py > Step 0 > getting g_file_ptr for /foo/bar > getting uri_ptr with 8093280 > free g_file_ptr > getting uri > free uri_ptr > Step 1 > getting g_file_ptr for /foo/bar > getting uri_ptr with 8093344 > free g_file_ptr > getting uri > free uri_ptr > Step 2 > getting g_file_ptr for /foo/bar > getting uri_ptr with 8093824 > free g_file_ptr > getting uri > free uri_ptr > Step 3 > getting g_file_ptr for /foo/bar > getting uri_ptr with 8093440 > free g_file_ptr > getting uri > free uri_ptr > Step 4 > getting g_file_ptr for /foo/bar > getting uri_ptr with 8093472 > free g_file_ptr > getting uri > free uri_ptr > Step 5 > getting g_file_ptr for /foo/bar > getting uri_ptr with 8093856 > free g_file_ptr > getting uri > free uri_ptr > Step 6 > getting g_file_ptr for /foo/bar > getting uri_ptr with 140176928020160 > free g_file_ptr > Erreur de segmentation (core dumped) > > > As you can see segfault happens as soon as the pointer position is outside > [0, 2^31[. > This is why I tried messing with argument/response types. > What am I doing wrong? Any pointer (ahah) on how to solve my problem? > > The c code can be compiled that way: > $ gcc $(pkg-config --cflags gio-2.0) segfault.c -o segfault $(pkg-config > --libs gio-2.0) > > Thanks > Bruno > -- https://mail.python.org/mailman/listinfo/python-list
Re: What is elegant way to do configuration on server app
Chris Angelico : > The number of cases where this matters is fairly low. Doing the reload > asynchronously is generally sufficient. Not sure. Not sure at all. Issues like this occupy a great part of my office hours. > And even if you have something that waits for the reload to finish, > you'll usually fire-and-forget that command anyway. The command systemctl reload xyz.service is supposed to return when the service is happily running with the updated its configuration. Any failures should be reported with a nonzero exit code from "systemctl". > For maximum portability, most programs are going to want to continue > to respond to SIGHUP, even if they do a systemd-triggered reload some > other way. I disagree. You can't just assume you can send a SIGHUP to a daemon for the LOLs. You must first discover the trick in the documentation. The default reaction to SIGHUP is to crash. A daemon (which has detached from the controlling terminal) is within its rights to do just that. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Sudoku solver
On Sat, Mar 28, 2015 at 12:14 AM, Dave Angel wrote: > But now I have to disagree about "true Sudoku puzzle." As we said earlier, > it might make sense to say that puzzles that cannot be solved that way are > not reasonable ones to put in a human Sudoku book. But why isn't it a "true > Sudoku puzzle"? > > Isn't the fact that one resorts to trial and error simply a consequence of > the fact that he/she has run out of ideas for more direct rules and the data > structures to support them? > > The simpler rules can be built around a list of possible values for each > cell. More complex rules can have a more complex data structure for each > cell/row/column/box. And when you run out of ideas for all those, you use > guess and backtrack, where the entire board's state is your data structure. At that point, it may make a fine mathematical curiosity, but it's not really a fun puzzle any more. Does "true" mean "playable"? I mean, I could devise a game in which you point your gun anywhere and shoot, and you kill someone and score 100 points, and no matter what you do, you can't die, and the game never ends. No strategy, no challenge. No goal. Is that a game? Well, it's virtually the same thing as any other FPS, just with a few simplifications. Is it fun? Not very. So is it a "true game"? (This is not purely theoretical, incidentally. I'm currently alpha testing a new game that I backed on Kickstarter. The Linux version is built against a different libc than I have, so to make it even run, I have to jump through some crazy hoops; it's slow, clunky, and not exactly a fun game... yet. The alpha isn't designed to be entertaining, it's designed to be a proof-of-concept and to let a bunch of testers find issues before they go to a wider audience. Eventually it'll become a fun game, but at the moment, firing it up is work. Does that mean it's "not a true game" yet? Philosophical debate!) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: ctypes problem: segfault with pointer usage
On Sat, Mar 28, 2015 at 12:22 AM, Bruno Cauet wrote: > Found the problem: I just have to add libgio.g_object_unref.argtypes = > [ctypes.c_void_p] > It now works flawlessly! Sorry for the noise. Glad you solved it! I had a quick look at your email, but since you attached your code rather than including it in-line, I would have had to fiddle around a bit (Gmail won't let me just look at a .py attachment in the browser, I have to download it and open it in my editor). Tip: Next time, include your code in the body of the email, and people are that much more likely to look at it. Of course, the rubber-ducking effect isn't affected by this :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: What is elegant way to do configuration on server app
On Sat, Mar 28, 2015 at 12:23 AM, Marko Rauhamaa wrote: > Chris Angelico : > >> The number of cases where this matters is fairly low. Doing the reload >> asynchronously is generally sufficient. > > Not sure. Not sure at all. Issues like this occupy a great part of my > office hours. Only because your office hours are occupied by problems, not by the cases that work flawlessly. You don't see the innumerable times that fire-and-forget works fine :) >> And even if you have something that waits for the reload to finish, >> you'll usually fire-and-forget that command anyway. > > The command > >systemctl reload xyz.service > > is supposed to return when the service is happily running with the > updated its configuration. > > Any failures should be reported with a nonzero exit code from > "systemctl". Sure. But how often do you actually need that, compared to the number of times when you deploy an updated config that was working fine on your test system, signal a reload, and off you go? You don't need to wait for it to finish; you'll see errors in the log, if there are any, and most likely there won't (your test system IS virtually identical to live, right?). I have scripts that edit config files and pop off SIGHUPs, usually in response to external events, and they neither need nor want to wait. It's pretty common. >> For maximum portability, most programs are going to want to continue >> to respond to SIGHUP, even if they do a systemd-triggered reload some >> other way. > > I disagree. You can't just assume you can send a SIGHUP to a daemon for > the LOLs. You must first discover the trick in the documentation. > > The default reaction to SIGHUP is to crash. A daemon (which has detached > from the controlling terminal) is within its rights to do just that. Sure it can, and you do need to know what you're sending signals to. But if you're unsure how to reload a daemon, the easiest way to probe it is to send it a SIGHUP (on your test system, of course), and see if it's still running afterwards. And once you know that this process responds thusly to SIGHUP, you can do this many *many* times more, never needing to worry about it. I would guess that there are hundreds, maybe thousands, of times when you can safely fire-and-forget, for every one that you actually need to wait on it - where you need some other action to be delayed until the reload is complete. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Sudoku solver
"Dave Angel" wrote in message news:[email protected]... > > But now I have to disagree about "true Sudoku puzzle." As we said > earlier, it might make sense to say that puzzles that cannot be solved > that way are not reasonable ones to put in a human Sudoku book. But why > isn't it a "true Sudoku puzzle"? > It seems you are correct. According to Wikipedia http://en.wikipedia.org/wiki/Glossary_of_Sudoku - A puzzle is a partially completed grid. The initially defined values are known as givens or clues. A proper puzzle has a single (unique) solution. A proper puzzle that can be solved without trial and error (guessing) is known as a satisfactory puzzle. An irreducible puzzle (a.k.a. minimum puzzle) is a proper puzzle from which no givens can be removed leaving it a proper puzzle (with a single solution). It is possible to construct minimum puzzles with different numbers of givens. The minimum number of givens refers to the minimum over all proper puzzles and identifies a subset of minimum puzzles. So what I am talking about is called a "satisfactory" puzzle, which is a subset of a "proper" puzzle. Frank -- https://mail.python.org/mailman/listinfo/python-list
Re: Sudoku solver
On 03/27/2015 09:25 AM, Chris Angelico wrote: On Sat, Mar 28, 2015 at 12:14 AM, Dave Angel wrote: But now I have to disagree about "true Sudoku puzzle." As we said earlier, it might make sense to say that puzzles that cannot be solved that way are not reasonable ones to put in a human Sudoku book. But why isn't it a "true Sudoku puzzle"? Isn't the fact that one resorts to trial and error simply a consequence of the fact that he/she has run out of ideas for more direct rules and the data structures to support them? The simpler rules can be built around a list of possible values for each cell. More complex rules can have a more complex data structure for each cell/row/column/box. And when you run out of ideas for all those, you use guess and backtrack, where the entire board's state is your data structure. At that point, it may make a fine mathematical curiosity, but it's not really a fun puzzle any more. That's why I addressed my comments at Frank. You and I are already in rough agreement about what makes a human game worthwhile: it has to be easy enough to be solvable, and hard enough to be challenging. Those cutoffs differ from one person to another, and from one age group to another. At one time (50+ years ago) I though Tic-Tac-Toe was tricky enough to be fun, but now it's always a draw, and only playable against a kid. On the other hand, I play some "games" which I can only solve with the aid of a computer. Is that "cheating"? Not for some games. I have some challenges for which I need/prefer to use a wrench, or a screwdriver, or a lawnmower. That doesn't make them less fun, just different fun. But I took Frank's comments as defining the "fine mathematical curiosity," and I have more interest in those than I generally do in "games". Many games that I hear people talking about, I've never even tried. I have a "TV set" which has never been hooked up to an antenna or cable. Only to CD/DVD/BluRay/computer/tablet/cellphone. So I'm a bit strange. I still enjoy riding a motorcycle, walking on the beach, or seeing a sunset from the backyard. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: Sudoku solver
On 03/27/2015 09:35 AM, Frank Millman wrote: "Dave Angel" wrote in message news:[email protected]... But now I have to disagree about "true Sudoku puzzle." As we said earlier, it might make sense to say that puzzles that cannot be solved that way are not reasonable ones to put in a human Sudoku book. But why isn't it a "true Sudoku puzzle"? It seems you are correct. According to Wikipedia http://en.wikipedia.org/wiki/Glossary_of_Sudoku - A puzzle is a partially completed grid. The initially defined values are known as givens or clues. A proper puzzle has a single (unique) solution. A proper puzzle that can be solved without trial and error (guessing) is known as a satisfactory puzzle. An irreducible puzzle (a.k.a. minimum puzzle) is a proper puzzle from which no givens can be removed leaving it a proper puzzle (with a single solution). It is possible to construct minimum puzzles with different numbers of givens. The minimum number of givens refers to the minimum over all proper puzzles and identifies a subset of minimum puzzles. So what I am talking about is called a "satisfactory" puzzle, which is a subset of a "proper" puzzle. Thanks for the wikipedia reference. Now we're in violent agreement, and even have a vocabulary to use for that agreement. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: Supply condition in function call
On Friday, March 27, 2015 at 10:05:21 AM UTC+5:30, Steven D'Aprano wrote: > On Fri, 27 Mar 2015 01:21 pm, Rustom Mody wrote: > > > Anyway my point is that in python (after 2.2??) saying something is an > > object is a bit of a tautology -- ie verbiage without information. > > > Er, it's *always* been a tautology. Every value in Python is an object, > including classes, and that has been always the case. > > However, just because it's a tautology doesn't mean it isn't useful to know. > (Tautologies are also known as *facts* and knowing facts is usually a good > thing.) For the majority of programming languages, it is not the case that > all values are objects, and not all people reading the documentation should > be expected to know that this applies to Python. I am making a point of pedagogy not semantics. This is help(filter) for python 2 and 3. Python2: Help on built-in function filter in module __builtin__: filter(...) filter(function or None, sequence) -> list, tuple, or string Return those items of sequence for which function(item) is true. If function is None, return the items that are true. If sequence is a tuple or string, return the same type, else return a list. -- Python 3 Help on class filter in module builtins: class filter(object) | filter(function or None, iterable) --> filter object | | Return an iterator yielding those items of iterable for which function(item) | is true. If function is None, return the items that are true. | | Methods defined here: | | __getattribute__(self, name, /) | Return getattr(self, name). | | __iter__(self, /) | Implement iter(self). | | __new__(*args, **kwargs) from builtins.type | Create and return a new object. See help(type) for accurate signature. | | __next__(self, /) | Implement next(self). | | __reduce__(...) | Return state information for pickling. Try and put yourself in the place of a noob: Knows some C, not much else. Starts studying python. Good until a point. Then suddenly hit... map, filter, and the worst of all lambda. More he reads less he understands. Tries help... Gets the above. So which do you think helps him more python 2 or 3? -- https://mail.python.org/mailman/listinfo/python-list
Re: Sudoku solver
"Frank Millman" : > So what I am talking about is called a "satisfactory" puzzle, which is > a subset of a "proper" puzzle. That is impossible to define, though, because some people are mental acrobats and can do a lot of deep analysis in their heads. What's satisfactory to you may not be satisfactory to me. Besides, looking for "satisfactory" patterns can involve a truckload of trial and error. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Sudoku solver
On Sat, Mar 28, 2015 at 12:48 AM, Dave Angel wrote: > On the other hand, I play some "games" which I can only solve with the aid > of a computer. Is that "cheating"? Not for some games. I have some > challenges for which I need/prefer to use a wrench, or a screwdriver, or a > lawnmower. That doesn't make them less fun, just different fun. And I'm presently engaged in a very enjoyable task which most people wouldn't call a game, but probably more like torture. I'm listening to two different audio tracks (one on the left speaker, one on the right), making adjustments to one of them to bring it into alignment with the other. Not at all less fun... VERY different fun :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Sudoku solver
On Sat, Mar 28, 2015 at 12:56 AM, Marko Rauhamaa wrote: > "Frank Millman" : > >> So what I am talking about is called a "satisfactory" puzzle, which is >> a subset of a "proper" puzzle. > > That is impossible to define, though, because some people are mental > acrobats and can do a lot of deep analysis in their heads. What's > satisfactory to you may not be satisfactory to me. > > Besides, looking for "satisfactory" patterns can involve a truckload of > trial and error. Not really. I already gave a broad generation algorithm, capable of generating puzzles at any difficulty you choose. (Well, maximum difficulty. If you tell it "generate HARD puzzles", it might still generate a MEDIUM or EASY one. But you could post-filter for that.) The only back-tracking required is at the last step, where it seeks to minimize the number of clue digits - an optional step, and one that involves very little backtracking. I think you subsequently posted code which does broadly the same thing, but without the difficulty-class checks. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Sudoku solver
On 03/27/2015 09:56 AM, Marko Rauhamaa wrote: "Frank Millman" : So what I am talking about is called a "satisfactory" puzzle, which is a subset of a "proper" puzzle. That is impossible to define, though, because some people are mental acrobats and can do a lot of deep analysis in their heads. What's satisfactory to you may not be satisfactory to me. Besides, looking for "satisfactory" patterns can involve a truckload of trial and error. I know, let's use "regular expressions" -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: asyncio
On Fri, Mar 27, 2015 at 6:38 AM, Marko Rauhamaa wrote: > I don't know the answer to your question. A superficial glance at the > relevant asyncio source code (and documentation) suggests you shouldn't > be seeing what you are seeing. > > Tasks are kept in a weak set. Tasks should evaporate as soon as nobody > references them. Actually I think this explains it. In the OP's while loop, he updates his task list with the line: tasks = asyncio.Task.all_tasks(loop) This creates a strong reference to each of the returned tasks. When the loop comes back around, it calls all_tasks again, creating a second strong reference to each task, then assigns the resulting set to tasks, allowing the original set to be collected. At no point in the loop is there ever not a strong reference to each task. So if asyncio is relying on GC to prune its task set, they will never be cleaned up. To the OP: try deleting the tasks variable after you print it out. I bet this will solve your problem. -- https://mail.python.org/mailman/listinfo/python-list
Re: Supply condition in function call
On Sat, Mar 28, 2015 at 12:48 AM, Rustom Mody wrote: > Knows some C, not much else. > Starts studying python. > Good until a point. > Then suddenly hit... map, filter, and the worst of all lambda. > More he reads less he understands. > Tries help... Gets the above. > > So which do you think helps him more python 2 or 3? Python 3, because scaring someone off filter() might push him towards comprehensions instead :) No, seriously: I wouldn't expect anyone to be using help(filter) in that way. Someone who knows C and not much Python is simply not going to stumble upon filter, but will have a task/problem in mind. From there, either the online documentation or a Q&A forum like this or Stack Overflow will be the next port of call, not the help for one particular function. And frankly, if someone says "what you want is filter()" and doesn't explain what it does, why it's useful, and why it's better than a list comp/genexp, is doing a poor job of helping. The most common case of filter can be trivially converted into a genexp: filter(lambda x: some_expression, some_iterable) (x for x in some_iterable if some_expression) Unlike map(), filter() doesn't accept multiple iterables, so you don't even need to worry about zip(). The only time you really need filter() is when you're using a pre-existing function, and even then, a genexp is often not much worse: filter(int, list_of_strings) (s for s in list_of_strings if int(s)) Instead of building up more and more complex nestings of map, filter, etc, just go straight to a genexp (or a list comp, if you're about to wrap it in list()) and add the complexity you need. Teaching a new Python programmer about comprehensions is MUCH more useful than teaching him/her about map and filter. So, no. I don't think the help() difference between Py2 and Py3 is going to be much of a problem to a new programmer who knows only C. Maybe one who knows only LISP, but not one who knows C. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Sudoku solver
On Sat, Mar 28, 2015 at 1:09 AM, Dave Angel wrote: > On 03/27/2015 09:56 AM, Marko Rauhamaa wrote: >> >> "Frank Millman" : >> >>> So what I am talking about is called a "satisfactory" puzzle, which is >>> a subset of a "proper" puzzle. >> >> >> That is impossible to define, though, because some people are mental >> acrobats and can do a lot of deep analysis in their heads. What's >> satisfactory to you may not be satisfactory to me. >> >> Besides, looking for "satisfactory" patterns can involve a truckload of >> trial and error. >> > > I know, let's use "regular expressions" Part of me is quaking in fear... the other part looking on in morbid fascination. Can you build a regexp that proves a Sudoku grid solvable? OW! Okay, now all of me is quaking in fear. Please do not do this! Or maybe do. Ow. I can't decide. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: asyncio
Ian Kelly : > Actually I think this explains it. In the OP's while loop, he updates > his task list with the line: > > tasks = asyncio.Task.all_tasks(loop) > > This creates a strong reference to each of the returned tasks. Good catch! Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: asyncio
Marko Rauhamaa : > Ian Kelly : > >> Actually I think this explains it. In the OP's while loop, he updates >> his task list with the line: >> >> tasks = asyncio.Task.all_tasks(loop) >> >> This creates a strong reference to each of the returned tasks. > > Good catch! And demonstrates somewhat of a pitfall with weak references (which I have never used). Weak references are not as weak as they are thought to be. Marko -- https://mail.python.org/mailman/listinfo/python-list
Python counterpart of Elixir's build tool Mix - or: why is it so cumbersome to "create packages"
Hey, lately I was playing with elixir [1] and I found Mix [2], elixir's "build/task tool", to be amazing. Creating new projects, compiling, installing dependencies, running and testing -- really easy! For what I'm concerned mix convinced me just for the "mix new projectname" command: * creating README.md * creating .gitignore * creating mix.exs * creating config * creating config/config.exs * creating lib * creating lib/kv.ex * creating test * creating test/test_helper.exs * creating test/kv_test.exs It creates a reasonable skeleton which is the base for all the other mix commands. Yes, yes, there are skeleton generators for python, lots and lots of blog posts that describe the ideal project layout, setup.py for installing and testing, also lots and lots of blog posts about this... You can do all of the tasks with python. Mix just seems to be more "coherent". Sorry, for the little rant! Mix just made me reevaluate my python workflow again and I think there is room for improvement [4]. So what is you take on it? What is your workflow? Do you have any tips? Best, Stefan [1] http://elixir-lang.org/ [2] http://elixir-lang.org/getting-started/mix-otp/introduction-to-mix.html [3] http://elixir-lang.org/docs/v1.0/mix/ [4] I'm not really sorry for the rant. Getting a fresh perspective, a different point of view, is probably the main reason why one picks up new languagesand it worked this time :) -- https://mail.python.org/mailman/listinfo/python-list
Re: Supply condition in function call
On 27/03/2015 13:48, Rustom Mody wrote: On Friday, March 27, 2015 at 10:05:21 AM UTC+5:30, Steven D'Aprano wrote: On Fri, 27 Mar 2015 01:21 pm, Rustom Mody wrote: Anyway my point is that in python (after 2.2??) saying something is an object is a bit of a tautology -- ie verbiage without information. Er, it's *always* been a tautology. Every value in Python is an object, including classes, and that has been always the case. However, just because it's a tautology doesn't mean it isn't useful to know. (Tautologies are also known as *facts* and knowing facts is usually a good thing.) For the majority of programming languages, it is not the case that all values are objects, and not all people reading the documentation should be expected to know that this applies to Python. I am making a point of pedagogy not semantics. This is help(filter) for python 2 and 3. Python2: Help on built-in function filter in module __builtin__: filter(...) filter(function or None, sequence) -> list, tuple, or string Return those items of sequence for which function(item) is true. If function is None, return the items that are true. If sequence is a tuple or string, return the same type, else return a list. -- Python 3 Help on class filter in module builtins: class filter(object) | filter(function or None, iterable) --> filter object | | Return an iterator yielding those items of iterable for which function(item) | is true. If function is None, return the items that are true. | | Methods defined here: | | __getattribute__(self, name, /) | Return getattr(self, name). | | __iter__(self, /) | Implement iter(self). | | __new__(*args, **kwargs) from builtins.type | Create and return a new object. See help(type) for accurate signature. | | __next__(self, /) | Implement next(self). | | __reduce__(...) | Return state information for pickling. Try and put yourself in the place of a noob: Knows some C, not much else. Starts studying python. Good until a point. Then suddenly hit... map, filter, and the worst of all lambda. More he reads less he understands. Tries help... Gets the above. So which do you think helps him more python 2 or 3? Can't say it bothers me personally as I never use Python 2 any more. What does bother me is the stream of complaints you make about the docs or docstrings but there are very few if any tracker issues to get these things sorted. -- 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: Sudoku solver
On 27/03/2015 14:09, Dave Angel wrote: On 03/27/2015 09:56 AM, Marko Rauhamaa wrote: "Frank Millman" : So what I am talking about is called a "satisfactory" puzzle, which is a subset of a "proper" puzzle. That is impossible to define, though, because some people are mental acrobats and can do a lot of deep analysis in their heads. What's satisfactory to you may not be satisfactory to me. Besides, looking for "satisfactory" patterns can involve a truckload of trial and error. I know, let's use "regular expressions" Thanks, I've been having a miserable day but that got me chuckling :) -- 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 elegant way to do configuration on server app
On 2015-03-27, Jerry OELoo wrote: >>> Make a part of your event loop (assuming your server runs an event >>> loop) that wakes up every N seconds (e.g. every 60 seconds) and >>> checkes the file's modification timestamp again; if it's newer, record >>> that value for future comparisons, then re-read the file for its >>> values. >> >> That sounds rather Windowsesque. The more-or-less standard way to do >> handle the situation on Unix is to reread the config file when you get >> a SIGHUP. > > Why use SIGHUP, It's just tradition. Some other seldom-used signal could have been chosen, but way back when somebody chose SIGHUP, and other people followed suit. > Does it has something to do with configure file modification? Not intrinsically. It's just a convention in the Unix world that sending SIGHUP to a daemon will cause it to re-read its configuration files. I presume that automagically reading them any time they changed was both too much hassle and possibly dangerous: if a file is being edited, it might get saved in intermediate (broken) states during the editing session. -- Grant Edwards grant.b.edwardsYow! An air of FRENCH FRIES at permeates my nostrils!! gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: What is elegant way to do configuration on server app
On 2015-03-27, Marko Rauhamaa wrote: > Grant Edwards : > >> That sounds rather Windowsesque. The more-or-less standard way to do >> handle the situation on Unix is to reread the config file when you get >> a SIGHUP. > > That, indeed, is the classic Unix way. However, Linux has now moved to > systemd: That's a bit of an overstatement. _Some_ distros have switched to systemd. None of my machines use it, and it's very rare in embedded systems. -- Grant Edwards grant.b.edwardsYow! Are we THERE yet? at My MIND is a SUBMARINE!! gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: What is elegant way to do configuration on server app
On Sat, Mar 28, 2015 at 3:28 AM, Grant Edwards wrote: > I presume that automagically reading them any time they changed was > both too much hassle and possibly dangerous: if a file is being > edited, it might get saved in intermediate (broken) states during the > editing session. Even more so if you have multiple files (look, for instance, at PostgreSQL configs, where you might make simultaneous and connected changes to several related files); if you change one and it's activated before you change another, it might even have security implications - although more likely, it'd cause an outage (when legit connections get rejected because you haven't yet added the permission lines). The same problem occurs with PHP-based web sites, but there you don't get the option of holding over for a SIGHUP, so you're just stuck with uploading a new version of your site file-by-file, or *maybe* attempting an atomic rename of a directory. If you're lucky. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: What is elegant way to do configuration on server app
Grant Edwards : > On 2015-03-27, Marko Rauhamaa wrote: >> That, indeed, is the classic Unix way. However, Linux has now moved >> to systemd: > > That's a bit of an overstatement. _Some_ distros have switched to > systemd. None of my machines use it, and it's very rare in embedded > systems. Much less of an overstatement than saying that the Python world has now moved to Python3. RHEL/CentOS/Fedora are there. OpenSuSE is there. Debian is there. Ubuntu is going there. I'm not an apologist of systemd. Just stating the situation. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: What is elegant way to do configuration on server app
On 2015-03-27, Chris Angelico wrote: > The same problem occurs with PHP-based web sites, but there you don't > get the option of holding over for a SIGHUP, so you're just stuck with > uploading a new version of your site file-by-file, or *maybe* > attempting an atomic rename of a directory. If you're lucky. I don't think that anybody using PHP can be considered "lucky". ;) -- Grant Edwards grant.b.edwardsYow! ANN JILLIAN'S HAIR at makes LONI ANDERSON'S gmail.comHAIR look like RICARDO MONTALBAN'S HAIR! -- https://mail.python.org/mailman/listinfo/python-list
Re: Sudoku solver
On Friday, March 27, 2015 at 7:10:54 AM UTC-7, Dave Angel wrote: > On 03/27/2015 09:56 AM, Marko Rauhamaa wrote: > > "Frank Millman" : > > > >> So what I am talking about is called a "satisfactory" puzzle, which is > >> a subset of a "proper" puzzle. > > > > That is impossible to define, though, because some people are mental > > acrobats and can do a lot of deep analysis in their heads. What's > > satisfactory to you may not be satisfactory to me. > > > > Besides, looking for "satisfactory" patterns can involve a truckload of > > trial and error. > > > > I know, let's use "regular expressions" > > > -- > DaveA You jest, but... http://www.perlmonks.org/?node_id=471168 -- https://mail.python.org/mailman/listinfo/python-list
Re: What is elegant way to do configuration on server app
On Thursday, March 26, 2015 at 4:19:33 PM UTC+8, Jerry OELoo wrote: > Hi. > I have used python to provide a web service app, it will running 7*24, > and it will return some data to client by API. http://jonpy.sourceforge.net/modpy.html Check the page of modpy and django. -- https://mail.python.org/mailman/listinfo/python-list
Re: Supply condition in function call
Peter Otten <[email protected]> writes: > Cameron Simpson wrote: > >> test1([0,1,2,3], [1,2,3,4], condition_test) >> >> This passes the local variables inside test1() to "condition" as a single >> parameter. Now, I grant that vars['i'] is a miracle of tediousness. So >> consider this elaboration: >> >> from collections import namedtuple >> >> condition_test = lambda vars: vars.i + vars.j > 4 >> >> def test1(a, b, condition): >> for i, j in zip(a,b): >> c = i + j >> vars = locals() >> varnames = list(vars.keys()) > > instead or pass the list of arguments explicitly, optionally with some > inspect fallback: > > $ cat pass_condition_inspect.py > import inspect > > def test3(a, b, condition, args=None): > if args is None: > args = inspect.getargspec(condition).args > > for i, j in zip(a,b): > c = i + j > _locals = locals() > if condition(*[_locals[name] for name in args]): > print("Foo", i, j) > > def condition(c, i): > return i * i > c > > test3([1, 2, 3], [2, 3, 4], condition) > print("---") > # note reverse order of argument names > test3([1, 2, 3], [2, 3, 4], condition, ["i", "c"]) > $ python3 pass_condition_inspect.py > Foo 3 4 > --- > Foo 1 2 > Foo 2 3 > Foo 3 4 > I'm just comparing the different solutions. For most of them, the logic and the costs/benefits are pretty clear to me. Can you elaborate on your code? I'm not clear what you are achieving with explicitly passing the arguments instead of simply passing some variant of the complete locals()-dictionary. -- A hundred men did the rational thing. The sum of those rational choices was called panic. Neal Stephenson -- System of the world http://www.graune.org/GnuPG_pubkey.asc Key fingerprint = 1E44 9CBD DEE4 9E07 5E0A 5828 5476 7E92 2DB4 3C99 -- https://mail.python.org/mailman/listinfo/python-list
Re: Supply condition in function call
Cameron Simpson writes:
> This passes the local variables inside test1() to "condition" as a
> single parameter. Now, I grant that vars['i'] is a miracle of
> tediousness. So consider this elaboration:
>
> from collections import namedtuple
>
> condition_test = lambda vars: vars.i + vars.j > 4
>
> def test1(a, b, condition):
>for i, j in zip(a,b):
> c = i + j
> vars = locals()
> varnames = list(vars.keys())
> varstupletype = namedtuple("locals", varnames)
> varstuple = varstupletype(*[ vars[k] for k in varnames ])
> if condition(varstuple):
>print("Foo")
>
> Here, the condition_test function/lambda uses "vars.i" and "vars.j",
> which i think you'll agree is easier to read and write. The price is
> the construction of a "namedtuple" to hold the variable name
> values. See:
>
> https://docs.python.org/3/library/collections.html#collections.namedtuple
>
This is probably getting off topic, but is there any relevant difference
or benefit to using namedtuple instead of something like types.SimpleNamespace?
https://docs.python.org/3/library/types.html#additional-utility-classes-and-functions
--
A hundred men did the rational thing. The sum of those rational choices was
called panic. Neal Stephenson -- System of the world
http://www.graune.org/GnuPG_pubkey.asc
Key fingerprint = 1E44 9CBD DEE4 9E07 5E0A 5828 5476 7E92 2DB4 3C99
--
https://mail.python.org/mailman/listinfo/python-list
Re: Sudoku solver
On 26/03/2015 00:07, Ian Kelly wrote: On Wed, Mar 25, 2015 at 2:31 PM, Marko Rauhamaa wrote: It takes about 2 seconds for my Python program to find the answer but it spends a total of 110 seconds to exhaust the problem space. The analogous C program finished the whole thing in 200 milliseconds. "Hard" for a human doesn't necessarily mean "hard" for a programmatic solver in this case. Try your solver on this one: $ cat sudoku2.dat . . . 7 . . . . . 1 . . . . . . . . . . . 4 3 . 2 . . . . . . . . . . 6 . . . 5 . 9 . . . . . . . . . 4 1 8 . . . . 8 1 . . . . . 2 . . . . 5 . . 4 . . . . 3 . . I tried the first puzzle you posted, and it took about a second. I then started running it on this one before I started typing up this post, and it hasn't finished yet. While that was running, I then tried running Norvig's solver on this puzzle, and it completed in about 0.07 seconds. I tried my own brute-force solver, which normally takes 100msec, and it took 2 seconds for your hard puzzle, about 20 times longer. (In a language using a bytecode interpreter, not Python.) Using Pypy, it took 90 seconds, instead of 1 second or so. So still possibly faster than a human (faster than me certainly). -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Proposal for new minor syntax
I would like to propose a new piece of syntax for the python language; .= In short, the operator is form of syntactic sugar, for instance consider the following code: hello = "hello world " hello = hello.strip() This could be written as: hello = "hello world " hello .= strip() In this slightly contrived example, the programmer saved (a small amount of) time when writing the code. With code with longer variable names, or lots of similar statements all in a row, this helps to keep code more concise. The operator would be constricted to one method or field on the right-hand side, which must belong to the object on the left hand side. Another example could be when using Linked Lists, instead of writing something like: loop_node = loop_node.next you could write: loop_node .= next Does this idea have any chance of acceptance if submitted as a PEP? What are the potential concerns I could consider with the syntax? Thanks, Jamie -- https://mail.python.org/mailman/listinfo/python-list
Re: Supply condition in function call
Manuel Graune wrote: > Peter Otten <[email protected]> writes: > >> Cameron Simpson wrote: >> >>> test1([0,1,2,3], [1,2,3,4], condition_test) >>> >>> This passes the local variables inside test1() to "condition" as a >>> single parameter. Now, I grant that vars['i'] is a miracle of >>> tediousness. So consider this elaboration: >>> >>> from collections import namedtuple >>> >>> condition_test = lambda vars: vars.i + vars.j > 4 >>> >>> def test1(a, b, condition): >>> for i, j in zip(a,b): >>> c = i + j >>> vars = locals() >>> varnames = list(vars.keys()) >> >> instead or pass the list of arguments explicitly, optionally with some >> inspect fallback: >> >> $ cat pass_condition_inspect.py >> import inspect >> >> def test3(a, b, condition, args=None): >> if args is None: >> args = inspect.getargspec(condition).args >> >> for i, j in zip(a,b): >> c = i + j >> _locals = locals() >> if condition(*[_locals[name] for name in args]): >> print("Foo", i, j) >> >> def condition(c, i): >> return i * i > c >> >> test3([1, 2, 3], [2, 3, 4], condition) >> print("---") >> # note reverse order of argument names >> test3([1, 2, 3], [2, 3, 4], condition, ["i", "c"]) >> $ python3 pass_condition_inspect.py >> Foo 3 4 >> --- >> Foo 1 2 >> Foo 2 3 >> Foo 3 4 >> > > I'm just comparing the different solutions. For most of them, the > logic and the costs/benefits are pretty clear to me. Can you > elaborate on your code? I'm not clear what you are achieving with > explicitly passing the arguments instead of simply passing some > variant of the complete locals()-dictionary. Positional arguments are the most common calling convention, and the resulting condition() function def condition(c, i): return i * i > c looks more natural to my eye than the def condition(d): return d["i"] * d["i"] > d["c"] or def condition(s): return d.i * d.i > d.c variants that you have to write when you follow Cameron's suggestions. You are basically trading cleaner condition() client functions for messier testX() calling code. You might also be able to reuse functions not written specifically for that interface. Example using the sum() builtin: test3([1, 2, 3], [10, 20, 30], sum, ("a", "j")) Not that sum() makes much sense here, but I hope you get the idea... -- https://mail.python.org/mailman/listinfo/python-list
SQLObject 3.0.0a1
Hello! I'm pleased to announce version 3.0.0a1, the first alpha of the upcoming release of branch 3.0 of SQLObject. What's new in SQLObject === Features * Support for Python 2 and Python 3 with one codebase! (Python version >= 3.4 currently required.) Minor features -- * Use fdb adapter for Firebird. * PyDispatcher (>=2.0.4) was made an external dependency. Development --- * Source code was made flake8-clean. Documentation - * Documentation is published at http://sqlobject.readthedocs.org/ in Sphinx format. Contributors for this release are Ian Cordasco, Neil Muller, Lukasz Dobrzanski, Gregor Horvath. For a more complete list, please see the news: http://sqlobject.org/News.html What is SQLObject = SQLObject is an object-relational mapper. Your database tables are described as classes, and rows are instances of those classes. SQLObject is meant to be easy to use and quick to get started with. SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite, Firebird, Sybase, MSSQL and MaxDB (also known as SAPDB). Python 2.6, 2.7 or 3.4+ is required. Where is SQLObject == Site: http://sqlobject.org Development: http://sqlobject.org/devel/ Mailing list: https://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss Archives: http://news.gmane.org/gmane.comp.python.sqlobject Download: https://pypi.python.org/pypi/SQLObject/3.0.0a1dev-20150327 News and changes: http://sqlobject.org/News.html Oleg. -- Oleg Broytmanhttp://phdru.name/[email protected] Programmers don't die, they just GOSUB without RETURN. -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new minor syntax
On Fri, Mar 27, 2015 at 2:24 PM, Jamie Willis
wrote:
> I would like to propose a new piece of syntax for the python language; .=
>
> In short, the operator is form of syntactic sugar, for instance consider the
> following code:
>
> hello = "hello world "
> hello = hello.strip()
>
> This could be written as:
>
> hello = "hello world "
> hello .= strip()
>
> In this slightly contrived example, the programmer saved (a small amount of)
> time when writing the code. With code with longer variable names, or lots of
> similar statements all in a row, this helps to keep code more concise.
>
> The operator would be constricted to one method or field on the right-hand
> side, which must belong to the object on the left hand side.
Do you mean that this would not be legal?
hello .= strip().upper().encode('utf-8')
Is there a reason you want to disallow that?
> Another example could be when using Linked Lists, instead of writing
> something like:
>
> loop_node = loop_node.next
>
> you could write:
>
> loop_node .= next
I realize this is just an example, but does anybody actually use
linked lists in Python outside of class assignments? It seems hard to
justify performance-wise since list is written in C, and if you need
to beat it, then you probably shouldn't be doing so in Python.
> Does this idea have any chance of acceptance if submitted as a PEP? What are
> the potential concerns I could consider with the syntax?
On the plus side it doesn't add any new keywords or conflict with any
existing syntax.
On the minus side it seems marginal in utility to me, as all it does
is save a bit of typing. The +=, etc. operators are backed by special
methods named __iadd__ etc. which allows the class author to provide
for the operation to be performed in-place, or to change the meaning
entirely use the operator as part of a DSL. This proposal doesn't have
any room that I can see for that sort of benefit.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new minor syntax
Interesting concept. I suppose it offers some small optimization opportunities, and clearly saves some possibly error-prone typing. You construct the object on the left-hand side, then just DUP_TOP to get its use on the RHS. A couple comments though: * "dot" is pretty invisible unless surrounded by stuff on both sides (as when used like "hello.strip()"). The canyon formed by the characters on either side, and the mostly white space in the middle tends to make it more visible. That's less the case when it's bounded by white space on one side. * Probably better to propose it on python-ideas. * Ideas are always better received when accompanied by working code. :-) Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Supply condition in function call
On 27Mar2015 21:02, Manuel Graune wrote:
Cameron Simpson writes:
This passes the local variables inside test1() to "condition" as a
single parameter. Now, I grant that vars['i'] is a miracle of
tediousness. So consider this elaboration:
from collections import namedtuple
condition_test = lambda vars: vars.i + vars.j > 4
def test1(a, b, condition):
for i, j in zip(a,b):
c = i + j
vars = locals()
varnames = list(vars.keys())
varstupletype = namedtuple("locals", varnames)
varstuple = varstupletype(*[ vars[k] for k in varnames ])
if condition(varstuple):
print("Foo")
Here, the condition_test function/lambda uses "vars.i" and "vars.j",
which i think you'll agree is easier to read and write. The price is
the construction of a "namedtuple" to hold the variable name
values. See:
https://docs.python.org/3/library/collections.html#collections.namedtuple
This is probably getting off topic,
I think it is on topic.
but is there any relevant difference
or benefit to using namedtuple instead of something like types.SimpleNamespace?
https://docs.python.org/3/library/types.html#additional-utility-classes-and-functions
Probably not. SimpleNamespace is much easier to construct; I hadn't thought of
it. As the doc remarks, a namedtuple is probably better for fixed records (eg
mapping out rows of a CSV file) because it will prevent you using the wrong
name. But for a comparison function SimpleNamespace is probably better.
Cheers,
Cameron Simpson
The Horn of Vengeance: When he pushes the horn button, the device produces
the sound of fingernails scraping on a blackboard, amplified beyond pain
threshold. If that doesn't work, the horn then plays the Pina Colada song.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new minor syntax
On 27/03/2015 20:48, Ian Kelly wrote: On Fri, Mar 27, 2015 at 2:24 PM, Jamie Willis wrote: I would like to propose a new piece of syntax for the python language; .= In short, the operator is form of syntactic sugar, for instance consider the following code: hello = "hello world " hello = hello.strip() This could be written as: hello = "hello world " hello .= strip() In this slightly contrived example, the programmer saved (a small amount of) time when writing the code. With code with longer variable names, or lots of similar statements all in a row, this helps to keep code more concise. The operator would be constricted to one method or field on the right-hand side, which must belong to the object on the left hand side. Another example could be when using Linked Lists, instead of writing something like: loop_node = loop_node.next you could write: loop_node .= next An alternate syntax might be: hello = .string() loop_node =. next With flexible white space either side of "." unless it is important that ".=" or "=." is a single token. I'm assuming that an isolated "." is not a valid starter symbol for anything else, other than a floating point constant such as hello =.3 On the minus side it seems marginal in utility to me, as all it does is save a bit of typing. The +=, etc. operators are backed by special methods named __iadd__ etc. which allows the class author to provide for the operation to be performed in-place, or to change the meaning entirely use the operator as part of a DSL. This proposal doesn't have any room that I can see for that sort of benefit. It needn't require that sort of support. It does just save typing in the same way that A += B does, and makes it a little clearer what is being expressed. Except that with A = .B, A will be evaluated twice. -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: asyncio
On Friday, March 27, 2015 at 7:17:26 AM UTC-7, Ian wrote: > On Fri, Mar 27, 2015 at 6:38 AM, Marko Rauhamaa wrote: > > I don't know the answer to your question. A superficial glance at the > > relevant asyncio source code (and documentation) suggests you shouldn't > > be seeing what you are seeing. > > > > Tasks are kept in a weak set. Tasks should evaporate as soon as nobody > > references them. > > Actually I think this explains it. In the OP's while loop, he updates > his task list with the line: > > tasks = asyncio.Task.all_tasks(loop) > > This creates a strong reference to each of the returned tasks. When > the loop comes back around, it calls all_tasks again, creating a > second strong reference to each task, then assigns the resulting set > to tasks, allowing the original set to be collected. At no point in > the loop is there ever not a strong reference to each task. So if > asyncio is relying on GC to prune its task set, they will never be > cleaned up. > > To the OP: try deleting the tasks variable after you print it out. I > bet this will solve your problem. I missed that part. Thanks! -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new minor syntax
Jamie Willis writes: > This could be written as: > > hello = "hello world " > hello .= strip() −1, “.=” is visually too similar to “=”. Syntax that is ambiguous at a glance is a cost when reading, and here I think the cost is great. > In this slightly contrived example, the programmer saved (a small amount > of) time when writing the code. Code is read much more often than it is written; we should optimise for reading effort, not writing effort. -- \ “The history of Western science confirms the aphorism that the | `\ great menace to progress is not ignorance but the illusion of | _o__)knowledge.” —Daniel J. Boorstin, historian, 1914–2004 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Sudoku solver
On 03/27/2015 07:09 AM, Dave Angel wrote: [snip] I know, let's use "regular expressions" This is totally OT, but... There was a recent (2015-03-23) item on The Daily WTF web site concerning regular expressions. Take a look at http://thedailywtf.com/articles/regularly-expressing-hate -=- Larry -=- -- https://mail.python.org/mailman/listinfo/python-list
Re: Supply condition in function call
On 03/26/2015 06:56 PM, Chris Angelico wrote: On Fri, Mar 27, 2015 at 12:41 PM, Rustom Mody wrote: [snip] After selecting the line above [inside python inside help(filter) ]for cut-pasting here, by mistake I pressed Ctrl-C rather than Ctrl-Shift-C An exception was thrown and the terminal remained in some sort of raw mode even after exiting python Yes, confirmed. It'll be something to do with what happens when you have 'less' and readline working together, probably. Tip: Use Ctrl-Insert rather than Ctrl-Shift-C. It's the more standard keystroke anyway. ChrisA It seems that many people are not aware of the standard Unix/Linux middle-click copy method. Highlight the selection you want copied, move the mouse cursor to the location you want it copied to and middle-click with the mouse. Works between programs as well as within a single program. And it copies directly without going through the clipboard. I use this all the time, VERY handy. It's been standard in Unix/Linux since forever... :-) -=- Larry -=- -- https://mail.python.org/mailman/listinfo/python-list
Re: time module vs. datetime module: plain language for beginners
On Wednesday, March 25, 2015 at 2:17:03 PM UTC-7, Jinghui Niu wrote: > I am learning python programming. One thing that gives me a lot of confusion > is the division of labours between the time module and the datetime module. > > As it turns out to be, time module is not only about time, it's about date > too. And datetime doesn't natively support timezone, you have to create one > for yourself. > > Why duplicate datetime module? What is the design rationale between this > division? Can't we just have one unified module that deals with dates and > times? Could someone please list some situations where the two modules are > actually useful in their own ways respectively? > > Explanation with not too much jargon is highly appreciated. Thanks in advance. Thank you all very much for such a great explanation. I have a follow-up question here: what is the best practice in dealing with repeating date/time? I see neither date module nore datetime module natively supports such datatype right now. Thanks. -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new minor syntax
On Sat, 28 Mar 2015 10:39:04 +1100, Ben Finney wrote: >Jamie Willis writes: > >> This could be written as: >> >> hello = "hello world " >> hello .= strip() > >?1, .= is visually too similar to =. can't be much worse than hello = "hello world", I think the dot next to the equal sign makes it very distinctive. The equal sign is something we are so visually used to that any small deviation gets immediately recognized by our brain. I may be wrong on this assumption... > >Syntax that is ambiguous at a glance is a cost when reading, and here I >think the cost is great. I think the bigger issue here is consistency. And I like my programming languages to sport consistent syntax and semantics. Or at least to remain onsistent unless there is a good reason not to. In Python the dot sign isn't an operator. It is a delimiter. So it feels odd for me to see it treated as an operator. More precisely, in Python, delimiters that form an augmented assignment operator consist of an operator followed by the equal sign delimiter. This proposal would be the only exception. I'm personally not very found of that. -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new minor syntax
On Fri, Mar 27, 2015 at 6:33 PM, Mario Figueiredo wrote: > On Sat, 28 Mar 2015 10:39:04 +1100, Ben Finney > wrote: > >>Jamie Willis writes: >> >>> This could be written as: >>> >>> hello = "hello world " >>> hello .= strip() >> >>?1, “.=” is visually too similar to “=”. > > can't be much worse than > > hello = "hello world", > > I think the dot next to the equal sign makes it very distinctive. The > equal sign is something we are so visually used to that any small > deviation gets immediately recognized by our brain. I may be wrong on > this assumption... It depends somewhat on context. In the variable-width font that I'm reading my email in, the dot looks like a single pixel and doesn't create much visual spacing either. It would be very easy to miss. In a terminal window with Courier New on the other hand, it does look distinctive enough to be noticeable. We should keep in mind though that our code isn't always going to be read in Courier New. -- https://mail.python.org/mailman/listinfo/python-list
Re: time module vs. datetime module: plain language for beginners
On Fri, Mar 27, 2015 at 6:31 PM, Jinghui Niu wrote: > On Wednesday, March 25, 2015 at 2:17:03 PM UTC-7, Jinghui Niu wrote: >> I am learning python programming. One thing that gives me a lot of confusion >> is the division of labours between the time module and the datetime module. >> >> As it turns out to be, time module is not only about time, it's about date >> too. And datetime doesn't natively support timezone, you have to create one >> for yourself. >> >> Why duplicate datetime module? What is the design rationale between this >> division? Can't we just have one unified module that deals with dates and >> times? Could someone please list some situations where the two modules are >> actually useful in their own ways respectively? >> >> Explanation with not too much jargon is highly appreciated. Thanks in >> advance. > > Thank you all very much for such a great explanation. I have a follow-up > question here: what is the best practice in dealing with repeating date/time? > I see neither date module nore datetime module natively supports such > datatype right now. Thanks. Do you mean recurrence rules like "every three hours" or "every two weeks" or "the third Saturday of every month"? There's nothing specific in the standard library for this, but check out the python-dateutil third-party package, specifically the dateutil.rrule module. -- https://mail.python.org/mailman/listinfo/python-list
Re: Sudoku solver
Chris Angelico wrote: Part of me is quaking in fear... the other part looking on in morbid fascination. Can you build a regexp that proves a Sudoku grid solvable? Well, it's *theoretically* possible, since there are a finite number of possible sudoku puzzles, so if nothing else you could just use an RE that explicitly matched all the solvable ones. I wouldn't like to have to write that RE out by hand, though. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Supply condition in function call
On Saturday, March 28, 2015 at 5:57:08 AM UTC+5:30, Larry Hudson wrote: > On 03/26/2015 06:56 PM, Chris Angelico wrote: > > On Fri, Mar 27, 2015 at 12:41 PM, Rustom Mody wrote: > [snip] > >> After selecting the line above [inside python inside help(filter) ]for > >> cut-pasting here, by mistake I pressed Ctrl-C rather than Ctrl-Shift-C > >> An exception was thrown and the terminal remained in some sort of raw mode > >> even after exiting python > > > > Yes, confirmed. It'll be something to do with what happens when you > > have 'less' and readline working together, probably. > > > > Tip: Use Ctrl-Insert rather than Ctrl-Shift-C. It's the more standard > > keystroke anyway. > > > > ChrisA > > > It seems that many people are not aware of the standard Unix/Linux > middle-click copy method. > > Highlight the selection you want copied, move the mouse cursor to the > location you want it > copied to and middle-click with the mouse. Works between programs as well as > within a single > program. And it copies directly without going through the clipboard. > > I use this all the time, VERY handy. It's been standard in Unix/Linux since > forever... :-) Neat Thanks -- https://mail.python.org/mailman/listinfo/python-list
Re: Sudoku solver
On Sat, 28 Mar 2015 01:19 am, Chris Angelico wrote:
> Part of me is quaking in fear... the other part looking on in morbid
> fascination. Can you build a regexp that proves a Sudoku grid
> solvable?
Perl's regular expressions can run arbitrary code using ?{...} which
technically makes them Turing Complete and capable of solving any problem
you can solve in any other language. However the code is written in Perl,
so I call that cheating :-)
Excluding that, the consensus seems to be that Perl's regexes are stronger
than Chomsky regular expressions, but nobody quite knows how much stronger.
It's likely that they are at least as powerful as context-free grammars,
but not as powerful as a Turing machine (excluding embedded Perl code), but
that covers a lot of ground in the hierarchy of language power:
http://en.wikipedia.org/wiki/Chomsky_hierarchy#The_hierarchy
So it's an open question as to whether or not you could prove a Sudoku grid
solvable using a Perl regex. Python regexes are less powerful than Perl's,
so if you can't do it in Perl, you can't do it in Python.
But, for what its worth, you can test for prime numbers using a regex:
re.match(r'^1?$|^(11+?)\1+$', '1'*n)
matches if the number n is composite, i.e. it's not a prime.
http://code.google.com/p/pyprimes/source/browse/src/pyprimes/awful.py
My intuition is that given a completed Sudoku grid, you should be able to
prove that it is valid using a Python regex, but given an incomplete one,
probably *not* prove that it is solvable. But I can't justify that in any
objective way.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: Sudoku solver
On Sat, 28 Mar 2015 05:18 am, [email protected] wrote: > On Friday, March 27, 2015 at 7:10:54 AM UTC-7, Dave Angel wrote: >> I know, let's use "regular expressions" >> >> >> -- >> DaveA > > You jest, but... > > http://www.perlmonks.org/?node_id=471168 I'm not a Perl expert, but I call that cheating, as it uses the ?{ ... } construct to embed Perl code in the regex. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Sudoku solver
Good test for pypy to see where it's speed sits between C and Python. -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new minor syntax
On Saturday, March 28, 2015 at 6:26:26 AM UTC+5:30, Ian wrote: > On Fri, Mar 27, 2015 at 6:33 PM, Mario Figueiredo wrote: > > On Sat, 28 Mar 2015 10:39:04 +1100, Ben Finney wrote: > > > >>Jamie Willis writes: > >> > >>> This could be written as: > >>> > >>> hello = "hello world " > >>> hello .= strip() > >> > >>?1, ".=" is visually too similar to "=". > > > > can't be much worse than > > > > hello = "hello world", > > > > I think the dot next to the equal sign makes it very distinctive. The > > equal sign is something we are so visually used to that any small > > deviation gets immediately recognized by our brain. I may be wrong on > > this assumption... > > It depends somewhat on context. In the variable-width font that I'm > reading my email in, the dot looks like a single pixel and doesn't > create much visual spacing either. It would be very easy to miss. In a > terminal window with Courier New on the other hand, it does look > distinctive enough to be noticeable. We should keep in mind though > that our code isn't always going to be read in Courier New. Dunno if related... One thing that is a bit laborious in python are object initializers: self.attr1 = field1 self.attr2 = field2 In VB one can do: with self .attr1 = field1 .attr2 = field2 (or something like that -- dont exactly remember the syntax) -- https://mail.python.org/mailman/listinfo/python-list
VB/Pascal with statement [was Re: Proposal for new minor syntax]
On Sat, 28 Mar 2015 03:18 pm, Rustom Mody wrote: > One thing that is a bit laborious in python are object initializers: > > self.attr1 = field1 > self.attr2 = field2 > > In VB one can do: > > with self > .attr1 = field1 > .attr2 = field2 > > (or something like that -- dont exactly remember the syntax) Pascal is another language with a construct like that, and there's a FAQ for it: https://docs.python.org/2/faq/design.html#why-doesn-t-python-have-a-with-statement-for-attribute-assignments -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: VB/Pascal with statement [was Re: Proposal for new minor syntax]
On Sat, Mar 28, 2015 at 5:26 PM, Steven D'Aprano wrote: > On Sat, 28 Mar 2015 03:18 pm, Rustom Mody wrote: > >> One thing that is a bit laborious in python are object initializers: >> >> self.attr1 = field1 >> self.attr2 = field2 >> >> In VB one can do: >> >> with self >> .attr1 = field1 >> .attr2 = field2 >> >> (or something like that -- dont exactly remember the syntax) > > > Pascal is another language with a construct like that, and there's a FAQ for > it: > > https://docs.python.org/2/faq/design.html#why-doesn-t-python-have-a-with-statement-for-attribute-assignments While I don't advocate the proposal, it does have an important difference from the one cited in the FAQ - albeit a Tim-grit difference: the Pascal version has implicit attribute notation, where the proposed has a leading dot. This eliminates the ambiguity, though without majorly improving readability. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: pycurl.error: (55, 'select/poll returned error')
Nagy László Zsolt writes: > When calling curl.perform() on a curl instance I get this: > > pycurl.error: (55, 'select/poll returned error') > > This error happens only if the file to be POST-ed is big enough. Last > week files were under 1GB and everything went fine. Files above about > 1GB cannot be sent over with curl. Web services sometimes have limits about the allowed size of uploaded files. I know about one web server application framework (Zope/ZServer) that simply shuts down its communication channel when it receives a too large file - such a behaviour can confuse the client. Maybe, in your case, the server side, too, does something unexpected when it receives large files? "select/poll" by itself has nothing to do with the size of files. It is used to get informed when one out a set of communication channels is ready (again) for interaction. In principle, it should not fail -- unless something strange happens to the communication channels. -- https://mail.python.org/mailman/listinfo/python-list
