Re: Best GUI for Python
On Monday 27 April 2015 16:55, Christian Gollwitzer wrote: > YMMV. Is non-BMP needed for any living non-esoteric language? I agree > that it is a big flaw, but still is useful for very many projects. Yes. The Unicode Supplementary Multilingual Planes (SMPs) are used for rare but still current East Asian characters (which means that some of your Chinese users may not be able to write their names without it), also some mathematics symbols (okay, that's *slightly* esoteric), as well as emoji. None of those uses are critical (unless you have a lot of Chinese users) but supporting the SMPs should not be considered optional. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: Best GUI for Python
On Mon, Apr 27, 2015 at 4:55 PM, Christian Gollwitzer wrote: > Am 27.04.15 um 01:06 schrieb Chris Angelico: >> >> On Mon, Apr 27, 2015 at 6:26 AM, Ben Finney >> wrote: >>> >>> It doesn't have to. By using the newer ‘tkinter.ttk’ library >>> https://docs.python.org/3/library/tkinter.ttk.html>, the GUI will >>> use native look-and-feel widgets. >>> >> Does the new library also deal with the ongoing issues with Unicode >> support? AIUI there's some fundamental problem with Tkinter which >> means that (possibly only on Windows?) non-BMP characters simply can't >> be displayed. > > > No. That is a fundamental limit in Tcl 8 (it uses UCS-2 to store strings), > and will probably only addressed in Tcl 9. ttk addresses mostly the theming > issue and is now "8 years new" (Tk 8.5a6) with a precursor (Tile) from ten > years ago. Right, so this is an ongoing issue (at least for now). >> To me, that's a pretty bad flaw - we should be aiming >> new projects at complete Unicode support, which means Python 3 and a >> good GUI toolkit. > > > YMMV. Is non-BMP needed for any living non-esoteric language? I agree that > it is a big flaw, but still is useful for very many projects. Maybe not for the language itself, but then, you can transliterate Chinese using nothing but Roman letters and Arabic numerals (all in ASCII), so merely proving that you can represent text doesn't necessarily mean everything. Mainly, SMP characters are used for things like musical notes, mathematical symbols, emoticons, and so on. (Also, I'm not sure of the current state of the art as regards Chinese and Japanese characters.) If you support only the BMP, then you're far better off than supporting only ASCII or only , to be sure, but it's still cutting out some characters. For a program that already exists, already works, and can't handle non-BMP characters, it's a small issue, and not one that I'd be recommending a complete GUI toolkit replacement for; but for a green-field project, I would strongly recommend using Python 3 and some toolkit which supports the full Unicode range. This is a problem that won't just "go away". As more SMP blocks get assigned, more people will start using them, and get frustrated at your program for not letting them. (And why should an end user need to know the difference between 😃 and ⍥, that the second one works and the first doesn't?) Unless you're willing to wait for a Python that ships Tcl 9, Tkinter is a choice that restricts your end users. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Function decorator having arguments is complicated
On Monday 27 April 2015 12:37, Makoto Kuwata wrote: > I want to ask Python experts about function decorator which has arguments. > > I feel that function decorator having arguments is complicated, > because three 'def' are nested: > > def multiply(n): > def deco(func): > def newfunc(*args, **kwargs): > return n * func(*args, **kwargs) > return newfunc > return deco Yes. But not that complicated -- it is only three levels, and the pattern is pretty simple: - outer function takes arguments and returns a decorator; - middle function is the decorator to be returned; - inner function is the new function returned by the decorator. So we start with a regular decorator: def deco(func): def newfunc(*args, **kwargs): return n * func(*args, **kwargs) return newfunc indent it one more level, and wrap it in a function: def multiply(n): # as above, indented one extra level What's really tricky is a decorator which can *optionally* take arguments or not: @decorator(x, y) def function(): ... # not the same as @decorate() @decorate def function(): ... > If function decorator notation could take arguments, > decorator definition would be more simple: Yes, but then we have to learn more syntax: @decorate @decorate n @decorate(n) @decorate() # uses the default for multiply could all be different. Although I agree with you that writing a decorator factory is a bit complicated, it is simple to break it up into individual sub-steps: * I know how to write a function that adapts or wraps another function. * I know how to write a decorator: write a function, indent it one extra level, and wrap it in an outer function; * I know how to write a decorator factory: write a decorator, indent it one extra level, and wrap it in an outer function; which could even be extended: * I know how to write a decorator-factory factory: write a decorator factory, indent it one extra level, and wrap it in an outer function. Saving one layer is not important enough to justify specialised syntax. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Clize 3.0b1: An argument parser that draws a CLI from your function sigature
Hello everyone! After a few years in development, I am proud to say Clize is landing its feet again and is now in beta for an upcoming release. You can try it out usingpip install --user clize=3.0b1and you can browse the docs athttps://clize.readthedocs.org/ For those who'd like an explanation before clicking links, here's Clize's 5-bullet point explanation: * Command-line interfaces are created by passing functions to `clize.run`. * Parameter types are deduced from the functions' parameters. * A ``--help`` message is generated from your docstrings. (Why does this still need to be a bullet point?) * Decorators can be used to reuse functionality across functions. * Clize can be extended with new parameter behavior. I am primarily looking for feedback on the documentation contents, and I need to source a FAQ page, but any feedback is welcome! If you are into that sort of thing, I've also just set up a G+ community for it at: https://plus.google.com/communities/10114600650079362 -- https://mail.python.org/mailman/listinfo/python-list
any visualization web framework ?
show task execution; data visualization; easy to set up; thanks -- https://mail.python.org/mailman/listinfo/python-list
mac os core dump from detached process
I'm using the double fork exec model as exemplified in http://code.activestate.com/recipes/278731-creating-a-daemon-the-python-way/ to run a django management command detached from any view. A database object is used to store/update information about the process. The command does have a log file and appears to work well on linux. However, on my developer colleague's mac using the django development server the job ends suddenly without passing through the try except finally that's supposed to capture information. I believe the only way it can do this is os._exit or an interrupt eg SIGSEGV etc etc. Is it possible to get core dumps on the Mac for debugging purposes? Would the detached process inherit flags etc etc from the starting process? I know little about OS X/Mach. -- Robin Becker -- https://mail.python.org/mailman/listinfo/python-list
Wrote a memoize function: I do not mind feedback
I started again with Python. In Clojure you have memoize. I thought it nice to have this in Python also. So I wrote it. With a Fibonacci function to show the usefulness. You can find it here: https://github.com/CecilWesterhof/PythonLibrary I love to hear what you think of it. And ideas for other functionalities are welcome also. Übung macht den Meister. -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof -- https://mail.python.org/mailman/listinfo/python-list
heapq - why no key= arg?
Looking at heapq, I see only nlargest/nsmallest provide a key= arg. What about other operations, such as heapify? Am I not understanding something? I suppose for other ops, such as heapify, I can only customize comparison by customizing the object comparison operators? -- Those who fail to understand recursion are doomed to repeat it -- https://mail.python.org/mailman/listinfo/python-list
Re: heapq - why no key= arg?
Neal Becker wrote: > Looking at heapq, I see only nlargest/nsmallest provide a key= arg. What > about other operations, such as heapify? Am I not understanding > something? nlargest/nsmallest() use the decorate-sort-undecorate pattern to avoid calculating the key more than once. For the other operations you'd have to calculate key(item) repeatedly for every item involved in the specific operation. > I suppose for other ops, such as heapify, I can only customize > comparison by customizing the object comparison operators? I'm sure someons's written a Heapq class that automatically decorates when an item is added and undecorates when one is looked up or removed. As I'm too lazy to look it up here's a sketch: $ cat myheapq.py import heapq from itertools import count class Heapq: def __init__(self, values, key): self.counter = count() self.key = key self.items = [(key(value), index, value) for index, value in zip(self.counter, values)] heapq.heapify(self.items) def push(self, value): heapq.heappush( self.items, (self.key(value), next(self.counter), value)) def pop(self): return heapq.heappop(self.items)[-1] def __str__(self): return str([item[-1] for item in self.items]) def __bool__(self): return not not self.items if __name__ == "__main__": h = Heapq([1, -2, -3, 4], key=abs) print(h) print(h.pop()) print(h) h.push(-5) print(h) while h: print(h.pop(), end=", " if h else "\n") $ python3 myheapq.py [1, -2, -3, 4] 1 [-2, 4, -3] [-2, 4, -3, -5] -2, -3, 4, -5 -- https://mail.python.org/mailman/listinfo/python-list
Re: Wrote a memoize function: I do not mind feedback
Cecil Westerhof wrote: > I started again with Python. In Clojure you have memoize. I thought it > nice to have this in Python also. So I wrote it. With a Fibonacci > function to show the usefulness. > You can find it here: > https://github.com/CecilWesterhof/PythonLibrary > > I love to hear what you think of it. > > And ideas for other functionalities are welcome also. Übung macht den > Meister. See also: https://docs.python.org/dev/library/functools.html#functools.lru_cache A bit hard to find unless you already know it's there. -- https://mail.python.org/mailman/listinfo/python-list
Re: Function decorator having arguments is complicated
Le lun. 27 avr. 2015 à 04:39, Makoto Kuwata a écrit : > > If function decorator notation could take arguments, > decorator definition would be more simple: > > def multiply(func, n): > def newfunc(*args, **kwargs): > return n * func(*args, **kwargs) > return newfunc > > @multiply 4 # ex: @decorator arg1, arg2, arg3 > def f1(x, y): > return x+y > > > How do you think about this idea? > David Beazley has a nice trick [1] to allow optional argument in decorators: def logged(func=None, level=logging.DEBUG, message=None): if func is None: return partial(logged, level=level, message=message) @wraps(func) def wrapper(*args, **kwargs): log.log(level, message) return func(*args, **kwargs) return wrapper I think that solve your problem nicely, and that it is quite readable. [1] Amongst a heap of other cool tricks, in his Python Cookbook Regards, Maxime -- https://mail.python.org/mailman/listinfo/python-list
Re: Best GUI for Python
Am 27.04.15 um 09:15 schrieb Steven D'Aprano: On Monday 27 April 2015 16:55, Christian Gollwitzer wrote: YMMV. Is non-BMP needed for any living non-esoteric language? I agree that it is a big flaw, but still is useful for very many projects. Yes. The Unicode Supplementary Multilingual Planes (SMPs) are used for rare but still current East Asian characters (which means that some of your Chinese users may not be able to write their names without it), also some mathematics symbols (okay, that's *slightly* esoteric), as well as emoji. OK current Chinese characters count in. Were these available in pre-unicode 16bit encodings? If not, how did they cope? Not rying to defend the BMP, but still wondering whether this is a new issue due to the switch from 16bit to unicode, or if people can finally use all characters thanks to unicode (software with full support). Emoji and rare math is somewhat more esoteric (given the limited codepoint space) None of those uses are critical (unless you have a lot of Chinese users) but supporting the SMPs should not be considered optional. I fully agree. Full unicode is one of the goals for Tcl9, but Tcl/Tk is missing manpower to actually implement that stuff (and people with skills in unicode platform APIs) Christian -- https://mail.python.org/mailman/listinfo/python-list
Re: Function decorator having arguments is complicated
On 04/27, Maxime S wrote: > Le lun. 27 avr. 2015 à 04:39, Makoto Kuwata a écrit : > > > > If function decorator notation could take arguments, > > decorator definition would be more simple: > > > > def multiply(func, n): > > def newfunc(*args, **kwargs): > > return n * func(*args, **kwargs) > > return newfunc > > > > @multiply 4 # ex: @decorator arg1, arg2, arg3 > > def f1(x, y): > > return x+y > > > > > > How do you think about this idea? > > > > David Beazley has a nice trick [1] to allow optional argument in decorators: > > def logged(func=None, level=logging.DEBUG, message=None): > if func is None: > return partial(logged, level=level, message=message) > > @wraps(func) > def wrapper(*args, **kwargs): > log.log(level, message) > return func(*args, **kwargs) > return wrapper That is a cool trick, thanks for sharing! -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Question Installing latest Python
On Mon, 27 Apr 2015 01:11 am, Φώντας Λαδοπρακόπουλος wrote: > Τη Κυριακή, 26 Απριλίου 2015 - 6:05:50 μ.μ. UTC+3, ο χρήστης Steven > D'Aprano έγραψε: >> On Mon, 27 Apr 2015 01:00 am, Φώντας Λαδοπρακόπουλος wrote: >> >> > Hello, >> > >> > Can you please tell me how to install latest Python 3.4.x without >> > disturbing the other default python v2.7.5 intallation that i currently >> > have on my VPS server and access it as Python 3? >> > >> > Thank you. >>> Not unless you tell us more about your setup. >> What operating system? Linux, OS X, Unix, Windows? >> 32-bit or 64-bit OS? >> Do you have root/Administrator access to the machine? >> If you are running Windows, do you have a C compiler? >> Have you read the instructions on the Python web site? >> >> -- >> Steven > > > Yes, sure: > > CentOS 7.1 > x64 bit > Root Access to the VPS (1) Go here: https://www.python.org/downloads/release/python-342/ (2) Choose the source distribution you want. Save it to your hard drive on the server you will be working on. (3) Unpack the file. Do you need help with unpacking? (4) cd into the unpacked directory. Read the README file. Any questions? (5) Run these three commands from the unpacked directory as a regular user, not root: ./configure make make test (6) Take careful note of any errors from those commands. Some warnings and errors may be harmless. Feel free to ask about them here. You may prefer to ignore normal output and only see errors: ./configure > /dev/null make > /dev/null make test > /dev/null If there are any errors you do not understand, STOP! Read the README file again. Does that tell you how to fix the problem? If not, ask for help before proceeding. (7) When you are satisfied that everything is okay run this: sudo make altinstall or if you prefer: su make altinstall (8) Test that everything works as expected by running these two commands: python -c "import sys; print sys.executable" python3.4 -c "import sys; print(sys.executable)" You should see something like this: /bin/python2.7 /usr/local/bin/python3.4 -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Testing scheduling
Hi everyone. I'm trying to test scheduling with asyncio. I have a function that executes call_later to run a method later in the future. Basically, what I'm trying to do is what you do in Twisted with the method callLater of a fictional Clock, to simulate time passage with the advance method. class ClientCalculationTestCase(unittest.TestCase): def setUp(self): self.tr = proto_helpers.StringTransportWithDisconnection() self.clock = task.Clock() self.proto = RemoteCalculationClient() self.tr.protocol = self.proto self.proto.callLater = self.clock.callLater self.proto.makeConnection(self.tr) def test_timeout(self): d = self.proto.add(9, 4) self.assertEqual(self.tr.value(), 'add 9 4\r\n') self.clock.advance(self.proto.timeOut) return self.assertFailure(d, ClientTimeoutError) Is there any way to do this with asyncio?. Thanks for any help provided. -- https://mail.python.org/mailman/listinfo/python-list
Re: Clize 3.0b1: An argument parser that draws a CLI from your function sigature
It would be nice if it could automatically generate the python code for 'clizing a function', i.e., from the example in https://clize.readthedocs.org/en/latest/ def hello_world(name=None, no_capitalize=False): ... being able to do clize.generate_py_code(hello_world) which would return something in the fashion of """ if __name__ == '__main__': ###process sys.argv ... name=sys.argv[1] no_capitalize=... hello_world(name=name, no_capitalize=no_capitalize) """ Sometimes you may want to eliminate dependencies. -- https://mail.python.org/mailman/listinfo/python-list
Re: Best GUI for Python
On Tue, 28 Apr 2015 12:54 am, Christian Gollwitzer wrote: > Am 27.04.15 um 09:15 schrieb Steven D'Aprano: >> On Monday 27 April 2015 16:55, Christian Gollwitzer wrote: >> >>> YMMV. Is non-BMP needed for any living non-esoteric language? I agree >>> that it is a big flaw, but still is useful for very many projects. >> >> Yes. >> >> The Unicode Supplementary Multilingual Planes (SMPs) are used for rare >> but still current East Asian characters (which means that some of your >> Chinese users may not be able to write their names without it), also some >> mathematics symbols (okay, that's *slightly* esoteric), as well as emoji. > > OK current Chinese characters count in. Were these available in > pre-unicode 16bit encodings? Certainly not :-) Unicode currently encodes over 74,000 CJK (Chinese/Japanese/Korean) ideographs, which is comfortably larger than 2**16, so no 16-bit encoding can handle the complete range of CJK characters. In fact, Unicode has projected that at least another five thousand characters will be added in version 8, and probably more beyond that. > If not, how did they cope? Mostly badly :-) Actually, that's probably unfair. The situation wasn't as bad as it could have been for a number of reasons: - In Korea, hanja (literally "Chinese characters") are mostly used for older historical documents and some names, so most new documents would be written entirely in hangul instead of Chinese ideographs. - In Japan, kanji (also literally "Chinese characters") are not the only option either. There is a choice between kanji and three other systems: hiragana is used for syllables and words for which there is either no kanji available, or the author doesn't know the kanji; katakana is used for foreign words, loan words, scientific and technical terms, the names of companies, for emphasis, and onomatopoeia (words that sound like the sound of the thing they describe, e.g. bling, splash, pow, fizz, cock-a-doodle-do, oink); rōmaji (literally "Roman letters"), although it is rare to use that to write Japanese; it's mostly used for communication with non-Japanese, and as an input system for entering kanji. - 16 bits is enough to do the most common Chinese characters. For less common characters, people can re-word the phrase, use alternative spelling, or use a custom font or image, depending on how important the exact correct character is considered. - When it comes to names, sometimes people can use a similar character. The nearest approximation in Latin languages would be if the preferred spelling of your name was Zöe Weiß and you wrote Zoe Weiss instead. - Vietnam hasn't used Chinese characters (Nôm) since the 1920s, except for limited use as decorative and ceremonial uses. Disclaimer: nearly all of the above is taken from Wikipedia, my personal knowledge of Chinese and Japanese is limited to "yum cha" and "banzai". Everything else is all Greek to me :-) Consequently actual speakers of CJK languages may have different opinions. > Not rying to > defend the BMP, but still wondering whether this is a new issue due to > the switch from 16bit to unicode, or if people can finally use all > characters thanks to unicode (software with full support). Emoji and > rare math is somewhat more esoteric (given the limited codepoint space) No, it is not a new issue. Legacy East-Asian encodings have the same problems. It will probably take many more years before the entire CJK character set is added to Unicode, simply because the characters left to add are obscure and rare. Some may never be added. E.g. in 2007 Taiwan withdrew a submission to add 6,545 characters used as personal names as they were deemed to no longer be in use. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Best GUI for Python
On 2015-04-26, Ben Finney wrote: > Steven D'Aprano writes: > >> Tkinter is easier to use, as it is standard with Python. So long as >> you have Tk/Tcl installed on your computer, Tkinter should work fine. >> >> However, Tkinter probably looks a bit more old fashioned. > > It doesn't have to. By using the newer ‘tkinter.ttk’ library >https://docs.python.org/3/library/tkinter.ttk.html>, the GUI will > use native look-and-feel widgets. I've tried using ttk, and it's not too bad on Windows, but it doesn't seem to help a jot on Linux. Most Linux users seem to be able to cope without a problem, but the old gray Motify look seems a bit dated. When I do try to use ttk on Linux, I just seem to end up with a mixture of two different completely non-native vaguely retro-looking widgets. -- Grant Edwards grant.b.edwardsYow! All this time I've at been VIEWING a RUSSIAN gmail.comMIDGET SODOMIZE a HOUSECAT! -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a python library to parse C++ code file?
I want to parse a C++ code to get class names, method names, the blocks inside method, methods inside method, identify recursive call, methods of class(outside the class), and relationships of classes. How to do it in python? Is there any library to do it? -- https://mail.python.org/mailman/listinfo/python-list
Re: Wrote a memoize function: I do not mind feedback
- Original Message -
> From: Peter Otten <__pete...@web.de>
> To: python-list@python.org
> Cc:
> Sent: Monday, April 27, 2015 4:28 PM
> Subject: Re: Wrote a memoize function: I do not mind feedback
>
> Cecil Westerhof wrote:
>
>> I started again with Python. In Clojure you have memoize. I thought it
>> nice to have this in Python also. So I wrote it. With a Fibonacci
>> function to show the usefulness.
>> You can find it here:
>> https://github.com/CecilWesterhof/PythonLibrary
>>
>> I love to hear what you think of it.
>>
>> And ideas for other functionalities are welcome also. Übung macht den
>> Meister.
>
> See also:
>
> https://docs.python.org/dev/library/functools.html#functools.lru_cache
>
> A bit hard to find unless you already know it's there.
If you Google for memoization decorator, you will easily find many more
implementations. Not 100 percent sure, but I think the LRU cache decorator was
not exactly light weight. I also like this one from Martelli's Python Cookbook,
where he uses a mutable default argument {a dictionary} to implement
memoization. I believe I went like this:
def some_func(arg, _memoize={}):
try:
return _memoize[arg]
except KeyError:
result = some_expensive_operation(arg)
_memoize[arg] = result
return result
--
https://mail.python.org/mailman/listinfo/python-list
Re: Best GUI for Python
Am 27.04.15 um 19:02 schrieb Grant Edwards: On 2015-04-26, Ben Finney wrote: Steven D'Aprano writes: Tkinter is easier to use, as it is standard with Python. So long as you have Tk/Tcl installed on your computer, Tkinter should work fine. However, Tkinter probably looks a bit more old fashioned. It doesn't have to. By using the newer ‘tkinter.ttk’ library https://docs.python.org/3/library/tkinter.ttk.html>, the GUI will use native look-and-feel widgets. I've tried using ttk, and it's not too bad on Windows, but it doesn't seem to help a jot on Linux. Most Linux users seem to be able to cope without a problem, but the old gray Motify look seems a bit dated. When I do try to use ttk on Linux, I just seem to end up with a mixture of two different completely non-native vaguely retro-looking widgets. Yes, the default theme is terrible on Linux (Mac & Windows uses native widgets). There are additional themes available, which are buried in some packages and a bit difficult to install, but give reasonable approximations to the QT look; I'm talking about plastik, for instance http://wiki.tcl.tk/24094 (1st picture - the layout of the test is terrible, but the widgets do look good). For some reason I've got no insights, these themes are very slow (they are based on displaying pre-rendered PNG images for the widget bits and pieces). Yet another possibility are the tileQT and tileGTK packages, which render the widgets using QT and GTK, but of course this introduces these dependencies and it might be simpler to just use QT or GTK natively. Christian -- https://mail.python.org/mailman/listinfo/python-list
An experiment with blocks of object code and other meta ideas.
I've been playing around with a experimental script language that executes
object code lists directly and am looking for others who might like to help.
The first version was written in python. The original idea came from
wondering if it is possible to replace python's byte code with nested
object code lists. As I worked on it, it became clear it would also make a
nice script language on it's own so I decided to test how it would work
independently of python first.
Currently it's implemented in scheme so it can be compiled to C and a stand
alone executable.
The design is simple enough that converting it to use python objects and
using the python C API should be fairly straight forward.
I can update the original written-in-python version if anyone is
interested. It's quite a bit behind the scheme version right now. It might
make an interesting module.
Here's a few command line examples...
==> def [hello] [
... (print "Hello World\n")
... ]
==> (hello)
Hello World
==> set a 23/41
==> set b 3/2
==> (+ a b)
169/82
==> for x [1 2 3 4 5] [
...(print x "\n")
... ]
1
2
3
4
5
==> set conds [
... (< a 6)
... (== b 2)
... not-done
... ]
==> let [a b not-done] [7 2 0]
==> (or conds)
1
==> (and conds)
0
And of course it does execute files too. :-)
{-- guess-my-number.mta
GUESS MY NUMBER GAME
The computer picks a number and you
try to guess it.
---}
def [guess] [
set n (random 10)
set msg "Guess a number from 0 to 10: "
loop [
(print msg)
catch error
[set g (int (read-line))]
if (not (empty? error))
[set msg "What?, guess again: "]
elif (> g n)
[set msg "Too high, guess again: "]
elif (< g n)
[set msg "Too low, guess again: "]
else
[break]
]
(print "Good guess!\n")
]
(guess)
I've been told it looks like a combination of scheme, tcl, and python.
This script-language tests a number of ideas I've been interested in.
Keywords are objects too! They can be bound to names and executed later in
another place or returned by expressions to be executed.
Blocks are nested lists of object code that can be passed around. Actually
programs are nested lists of object codes. It's just the outer most block.
These features make it an interesting meta language to experiment with.
If you think you may be interested in helping with this project, (It's open
source), you can find it here.
https://github.com/Ronald-Adam/magic-meta
https://github.com/Ronald-Adam/magic-meta/wiki/1.-Home
I'm hoping some of you may be interested in helping out as a group project
with the possibility of bringing some of the ideas back to python in some
form. Possibly as a script language that can be used in projects.
There is lots of opportunities to make improvements and additions as there
are zero users currently.
It's still very early in it's development, so don't expect too much at this
time.
Cheers,
Ron
--
https://mail.python.org/mailman/listinfo/python-list
Re: Clize 3.0b1: An argument parser that draws a CLI from your function sigature
On Mon, Apr 27, 2015 at 7:02 PM, Yann Kaiser wrote: > Hello everyone! > > After a few years in development, I am proud to say Clize is landing its > feet again and is now in beta for an upcoming release. > > You can try it out usingpip install --user clize=3.0b1and you can > browse the docs athttps://clize.readthedocs.org/ > > For those who'd like an explanation before clicking links, here's Clize's > 5-bullet point explanation: > > * Command-line interfaces are created by passing functions to `clize.run`. > * Parameter types are deduced from the functions' parameters. > * A ``--help`` message is generated from your docstrings. (Why does this > still need to be a bullet point?) > * Decorators can be used to reuse functionality across functions. > * Clize can be extended with new parameter behavior. Interesting. I've also been working on a simpler arg handling module; maybe we can work together. The goals for mine are: * Each function should be as independent as possible. * Minimize repetition (of names, descriptions, etc) * Keep everything in the function signature * Simplify the basic and obvious usages https://github.com/Rosuav/docstringargs https://pypi.python.org/pypi/docstringargs/ There's a demo file in the source repo, plus here are a couple of actual usage examples: https://github.com/Rosuav/LetMeKnow/blob/master/letmeknow.py https://github.com/MikeiLL/appension/blob/master/fore/database.py The latter is an existing module in an existing project, and it grew a command-line interface with minimal changes, eg: https://github.com/MikeiLL/appension/commit/566f195 Can we merge our plans and make a single module that's more likely to be maintained long-term? No point over-duplicating! ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a python library to parse C++ code file?
On Tue, 28 Apr 2015 04:33 am, buddingros...@gmail.com wrote: > I want to parse a C++ code to get class names, method names, the blocks > inside method, methods inside method, identify recursive call, methods of > class(outside the class), and relationships of classes. How to do it in > python? Is there any library to do it? Have you googled for "C++ parse python"? What results did you find? https://duckduckgo.com/?q=parse%20C%2B%2B%20python C++ is notorious for being so complex that it is very difficult to parse correctly. I believe that most so-called C++ parsers fail to parse it correctly (obviously some do, otherwise there would be no working C++ compilers). Perhaps SWIG may be able to help you? It claims to be able to export the parse tree of the C++ code as XML, which you could then analyse in Python. http://www.swig.org/compare.html http://www.swig.org/article_cpp.html -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: pypy3 kubuntu 14.04
On 26-04-2015 05:09, Paulo da Silva wrote: > Is there anybody using pypy3 in *ubuntu 14.04? > > I installed ppa:pypy/ppa but I still cannot see any pypy3! > All refs to pypy (using aptitude) show in the comments python 2.7! > > Thanks for any help. > For those who may be interested ...: OK, I found a binary tar in the download site that only needs to be unpacked in /opt, for ex., and then make a link to pypy3 somewhere in the unpacked dir from a dir in the PATH as /usr/local/bin. Unfortunateley numpy is not available for pypy3! So, not much useful for me :-( -- https://mail.python.org/mailman/listinfo/python-list
Re: Tit for tat
On Sun, 26 Apr 2015 22:50:03 -0700 (PDT), John Ladasky wrote: >On Sunday, April 26, 2015 at 6:41:08 PM UTC-7, Seymore4Head wrote: > >> Richard Dawkins explains with passion the idea of game theory and tit >> for tat, or why cooperation with strangers is often a strong strategy. >> >> He talks of a computer program tournament. I don't know what I could >> say that would be more interesting than just watching the video. > >Well, I'm not sure sure what any of this has to do with Python -- but since I >know something about the subject, I'll reply. > >That Richard Dawkins video is quite old -- it would appear to be from the >middle 1980's. Douglas Hofstadter's 1985 book, _Metamagical_Themas_, covered >this exact same material. A game called the "Iterated Prisoner's Dilemma" is >played (I'll abbreviate it as IPD). Humans can play, of course, but in this >case it is played by algorithms. An algorithm called "Tit for Tat" is >surprisingly simple and robust. When meeting a new contestant, Tit for Tat >plays nice in round 1; and on every subsequent round, it plays however that >opponent played the last time. > >Evolutionary biologists like Dawkins point to the success of Tit for Tat in >IPD as a model of how cooperation could emerge in a population of selfish >organisms. Now, in a round-robin IPD game, Tit for Tat wins pretty handily. >But in some other scenarios, as I recall, Tit for Tat is not a runaway winner. > >Suppose that instead of each strategy playing EVERY other, each strategy >inhabits a "territory" in a space, and each strategy only plays its neighbors. > In "rough neighborhoods", Tit for Tat can lose out to more punitive >strategies. If Tit for Tat is around more cooperative strategies, it thrives. > The boundaries between good neighborhoods and bad are chaotic. Tit for Tat >more or less holds the borders, but usually can't clean out a bad neighborhood. > >This finding came out many years after the Hofstadter and Dawkins reports, so >it's not covered in the video. My reference to the idea is a 1997 paper >entitled "The Undecidability of the Spatialized Prisoner's Dilemma," by >Patrick Grim (http://link.springer.com/article/10.1023%2FA%3A1004959623042). In the past, I have had some measure of success with the Toot for Tail strategy. -- https://mail.python.org/mailman/listinfo/python-list
Re: Clize 3.0b1: An argument parser that draws a CLI from your function sigature
On Tue, Apr 28, 2015 at 12:45 PM, Yann Kaiser wrote: > On Mon, 27 Apr 2015 at 17:04 Chris Angelico wrote: >> Interesting. I've also been working on a simpler arg handling module; >> maybe we can work together. The goals for mine are: >> >> * Each function should be as independent as possible. > > > In Clize, commands are also just regular functions which have the desired > amount of keyword-only parameters and annotations. They can still be run > individually, be tested, and so forth. To implement something like the examples I gave, though, you'd need to enumerate the subcommand functions at the end. I'd like to be able to not do that. My inspiration came partly from Flask. I can build up a web site with several separate files, where one file might define routes for all the human-accessible content (the stuff that's designed for a web browser) and a separate file could define the API endpoints (emitting JSON or something). There's no need to have a single gathering point that lists every function that needs to be called - they get squirreled away by the decorator. >> * Minimize repetition (of names, descriptions, etc) > > > I try to minimize repetition, but the reality of things is that a parameter > name could be repeated up to 4 times in Clize: > > * In the function's parameter list > * In the function's docstring > * If named explicitly, in a @-kwoargs decorator (not needed with Py3) > * In an annotate decorator (again, not needed with Py2 compatibility isn't > desired) > > Two of these wouldn't be relevant in a Python 3-only world (if it's just a > shell script replacement, you can probably pretend to be in one for a > moment), the remainder being normal things in a function. So I'm not doing > too badly there. Descriptions are of course only written in the description > :-) A lot of my projects are Py3-only. I have no problem with that. >> * Keep everything in the function signature > > I started taking this at heart with 3.0, after seeing the rather disgusting > constructs that had to be used in Clize 2.x for specifying aliases and value > converters. Now everything is annotations. Nothing in the docstring > specifies behavior, and it isn't even read at all until --help is triggered. > I intend to keep docstrings behavior-free because, well, they're strictly > for documentation IMO. > > What I mean to say, is that I am definitely committed to keeping everything > in the function signature. Probably even more than you :-) :) There's a spectrum of convenience: 1) The actual function signature - information that already exists. Function and parameter names, basically. 2) Annotations, directly attached to the parameters. 3) Docstrings and decorators, adjacent to the 'def' statement. 4) Code elsewhere in the file. 5) Code or directives in a separate file. Some of Clize stretches as far as level 4, and that's what I'd like to pull up a bit. With docstringargs, the only things at level 4 are generic setup - importing the module (unavoidable) and "if name is main, do stuff" (also unavoidable unless you want to put in some major MAJOR magic). (I took this spectrum from the discussions surrounding PEP 484, incidentally. I'm sure you won't be even *considering* having crucial command-line parsing out in a separate file, but that's precisely what type-hint stub files are.) >> There's a demo file in the source repo, plus here are a couple of >> actual usage examples: >> >> https://github.com/Rosuav/LetMeKnow/blob/master/letmeknow.py >> https://github.com/MikeiLL/appension/blob/master/fore/database.py >> >> The latter is an existing module in an existing project, and it grew a >> command-line interface with minimal changes, eg: >> >> https://github.com/MikeiLL/appension/commit/566f195 >> >> Can we merge our plans and make a single module that's more likely to >> be maintained long-term? No point over-duplicating! > > > Agreed. I'm open to have more maintainers and to take input, but I have to > admit that at this stage of development, I'm quite attached to Clize's > existing codebase and features (although I'm always open to refactoring, and > the test suite helps with that). If Clize can implement something comparably simple to what I'm doing in the above examples, I'd be happy to drop docstringargs in favour of it. Basically, I didn't like how argparse code looked: https://github.com/Rosuav/snippets/blob/master/snippets.py (That file actually has a deliberate bug in it, which I intended to use as a demo of 'git bisect', but so far, haven't had a chance to do that with my students yet.) Taking the 'put' subcommand as an example, we have these lines of code to handle the CLI: 2: generic boilerplate (import) 10: function signature 11-15: docstring 33-35: generic boilerplate (setup) 39: repetition of function name and purpose 40-41: repetition of function arguments, now with their purposes 48-51: generic boilerplate (execution) 53: repetition of function name 54: repetition of function name 60-61:
Re: Best GUI for Python
On Monday 27 April 2015 17:22, Chris Angelico wrote: > This is a problem that won't just "go away". As more SMP blocks get > assigned, more people will start using them, and get frustrated at > your program for not letting them. (And why should an end user need to > know the difference between 😃 and ⍥, that the second one works and > the first doesn't?) Unless you're willing to wait for a Python that > ships Tcl 9, Tkinter is a choice that restricts your end users. I'm not really arguing with you, just giving a slightly difference of emphasis... I don't think that failure to support the SMPs is a deal-breaker. Obviously, if you specifically need some subset of Unicode in the SMPs, say Phoenician, then it may be, but I'm just talking about general use. Given the generally poor support for non-ASCII characters many applications provide, any Unicode support is better than none. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: Clize 3.0b1: An argument parser that draws a CLI from your function sigature
On 04/28, Chris Angelico wrote:
> That's a lot of separate pieces. Here's the docstringargs equivalent:
>
> https://github.com/Rosuav/snippets/blob/dsa/snippets.py
Just for grins, here's that using Scription:
-- 8<
"""Store and retrieve snippets of text"""
from scription import *
import logging
# Set the log output file, and the log level
logging.basicConfig(filename="snippets.log", level=logging.DEBUG)
data = {}
@Script()
def main():
print('Result: {!r}'.format(script_command()))
@Command(
name=('the name of the snippet', ),
snippet=('the snippet text', ),
)
def put(name, snippet):
"Store a snippet with an associated name."
logging.info("Storing({!r}, {!r})".format(name, snippet))
data[name] = snippet
return name, snippet
@Command(
name=('the name of the snippet', ),
)
def get(name):
"Retrieve the snippet with a given name."
logging.error("Retrieving({!r})".format(name))
return data.get(name)
Main()
-- 8<
and a sample run with nothing selected:
-- 8<
$ python snippet
Store and retrieve snippets of text
snippet get NAME
Retrieve the snippet with a given name.
NAME the name of the snippet
snippet put NAME SNIPPET
Store a snippet with an associated name.
NAME the name of the snippet
SNIPPET the snippet text
-- 8<
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
Re: Best GUI for Python
On Tue, Apr 28, 2015 at 3:10 PM, Steven D'Aprano wrote: > On Monday 27 April 2015 17:22, Chris Angelico wrote: > >> This is a problem that won't just "go away". As more SMP blocks get >> assigned, more people will start using them, and get frustrated at >> your program for not letting them. (And why should an end user need to >> know the difference between 😃 and ⍥, that the second one works and >> the first doesn't?) Unless you're willing to wait for a Python that >> ships Tcl 9, Tkinter is a choice that restricts your end users. > > I'm not really arguing with you, just giving a slightly difference of > emphasis... > > I don't think that failure to support the SMPs is a deal-breaker. Obviously, > if you specifically need some subset of Unicode in the SMPs, say Phoenician, > then it may be, but I'm just talking about general use. Given the generally > poor support for non-ASCII characters many applications provide, any Unicode > support is better than none. I agree that it isn't _in itself_ a deal-breaker; it's a choice, but most choices restrict you, the programmer. Choosing to use Python rather than C restricts what you can do easily (but so would the converse choice); choosing to use SQLite3 restricts your ability to alter tables; choosing to use PyGTK forces you to include an external dependency. But choosing to use Tkinter restricts *your users* to BMP-only. That's a consideration that takes a bit more thought to evaluate; how bad is it? You can decide on the cost of a UTF-8 string type by figuring out how often you need to know about character lengths, but how can you know the cost of a UCS-2 font renderer? That's why I would be inclined to avoid Tkinter. Not because UCS-2 is a fundamental deal-breaker, but because it's too hard to truly evaluate the merits of the decision. Maybe external deps are just too costly (like for Idle), or maybe you just detest all the other options, and so maybe you'll end up coming back to Tk; but at the initial evaluation phase, I would push for something else if at all possible. There's often some sort of problem with non-ASCII text in a program that wasn't built for it. A lot of programs I use (including some that I've written) have issues with RTL text - particularly, issues with mixed RTL and LTR text on the same lines, which is a pretty hairy problem. But at least if a program uses Python 3, it has a good chance of getting most of it right. As you say, that's a huge advantage over so many applications. :( ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on the creation of list of lists
On 23/04/2015 2:18 AM, subhabrata.bane...@gmail.com wrote:
I have a list of file names of a directory, I want to read each one of them.
After reading each one of them, I want to put the results of each file in a
list.
These lists would again be inserted to create a list of lists.
While there's nothing wrong with for loops, Python does provide list
comprehensions which can help simplify list creation.
If you just want a list with each element being a list of the contents
of a file:
all_content = [ open(x, 'r').readlines() for x in list_of_files ]
If you want a list containing a list of filenames and another list
holding the content lists (which you seem to be wanting from your code):
files_and_content = zip(list_of_files, all_content)
Another useful way of storing data such as this is in a dictionary,
using the filenames as keys:
file_content = { x:open(x, 'r').readlines() for x in list_of_files }
What structure is most important is, of course, dependent on what you
want to do with it next.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Best GUI for Python
On Tuesday 28 April 2015 15:32, Chris Angelico wrote: > On Tue, Apr 28, 2015 at 3:10 PM, Steven D'Aprano > wrote: >> On Monday 27 April 2015 17:22, Chris Angelico wrote: >> >>> This is a problem that won't just "go away". As more SMP blocks get >>> assigned, more people will start using them, and get frustrated at >>> your program for not letting them. (And why should an end user need to >>> know the difference between 😃 and ⍥, that the second one works and >>> the first doesn't?) Unless you're willing to wait for a Python that >>> ships Tcl 9, Tkinter is a choice that restricts your end users. >> >> I'm not really arguing with you, just giving a slightly difference of >> emphasis... >> >> I don't think that failure to support the SMPs is a deal-breaker. >> Obviously, if you specifically need some subset of Unicode in the SMPs, >> say Phoenician, then it may be, but I'm just talking about general use. >> Given the generally poor support for non-ASCII characters many >> applications provide, any Unicode support is better than none. > > I agree that it isn't _in itself_ a deal-breaker; it's a choice, but > most choices restrict you, the programmer. Choosing to use Python > rather than C restricts what you can do easily (but so would the > converse choice); choosing to use SQLite3 restricts your ability to > alter tables; choosing to use PyGTK forces you to include an external > dependency. But choosing to use Tkinter restricts *your users* to > BMP-only. That's a consideration that takes a bit more thought to > evaluate; how bad is it? You can decide on the cost of a UTF-8 string > type by figuring out how often you need to know about character > lengths, but how can you know the cost of a UCS-2 font renderer? On the other hand, you can use something like QT, except that judging from claims made by the KDE 4 developers, QT has a bunch of Unicode-related bugs which they refuse to fix (the one which keeps biting me is that the application will suddenly decide I am typing right-to-left, and everything I type shows up in redro gnorw eht. Only restarting the application fixes it. I don't think that choosing UCS-2 only is any worse than any other application feature like "support only jpegs, not every obscure image format GIMP supports" or "choose to use floating point maths instead of some numeric type with unlimited precision". You are free to make whatever trade- offs you like, and your users are free to use another application :-) -- Steve -- https://mail.python.org/mailman/listinfo/python-list
