Re: Idiomatic backtracking in Python
On 26/01/2015 00:32, Ben Finney wrote: Johannes Bauer writes: So, I would like to ask if you have a Pythonic approach to backtracking problems? If so, I'd love to hear your solutions! I'm not aware of what the problem is. “Back-tracking” doesn't have a general meaning I recognise beyond random access into a data structure. So a Python list is the obvious starting point. Do you have a specific meaning of “back-tracking” that implies particular problems that are difficult to solve? As good a definition here http://en.wikipedia.org/wiki/Backtracking as any. As elsewhere in this thread it mentions sudoku. To me this http://norvig.com/sudoku.html is a classic example of putting theory into practice. Read and weep :) -- 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: __bases__ misleading error message
On 24/01/2015 13:43, Steven D'Aprano wrote: Mario Figueiredo wrote: > class Sub: > pass > > foo = Sub() > > Sub.__bases__ > foo.__bases__ > >The last statement originates the following error: > > AttributeError: 'Sub' object has no attribute '__bases__' It's a bit ambiguous, but the way to read it is to think of object as a synonym for instance. In my opinion it is not ambiguous, because as you say in Python an object is a synonym for instance. We can say in Python an object is an instance of the type object, that's all. And that's why everything is an object in Python: >>> isisntace(foo, object) # For every foo True So a class (a type) is an instance too (of its metaclass). Therefore, the message says that the Sub instance has no attribute '__bases__'. In fact the Sub object (instance) has no attribute '__bases__' because it is not an instance of type, and only types (classes) have this attribute. That means in Python sometimes, like the OP one, we have to underline the difference between types (classes) and non-types (non-classes) objects, instead of between objects and classes. The problem is in the Python documentation there is also a bit of confusion about this... In the descriptor howto: "The details of invocation depend on whether obj is an object or a class" :/ -- Marco Buttu INAF-Osservatorio Astronomico di Cagliari Via della Scienza n. 5, 09047 Selargius (CA) Phone: 070 711 80 217 Email: [email protected] -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Sanity Proposal: Type Hinting Solution
On 24/01/2015 15:09, Mario Figueiredo wrote: >def myfunction(arg1, arg2): > """ > Normal docstring. > @typehint: (str, int) -> bool""" > return True > >One of the problems with this is that it put the information about >parameters far away from the parameter list itself. Then move it to the first line of the docstring... I like this idea, because nevertheless the type hinting is optional, the mypy syntax affects every Python programmer who has to read other code that will use this syntax, while the docstring one does not. -- Marco Buttu INAF-Osservatorio Astronomico di Cagliari Via della Scienza n. 5, 09047 Selargius (CA) Phone: 070 711 80 217 Email: [email protected] -- https://mail.python.org/mailman/listinfo/python-list
HTTP over Asynchronous AF_UNIX Socket in python
Hi, The problem description: There are set of processes running on my system say `process_set_1`. Build a process agent which runs an `asynchronous` socket listening to incoming requests from process_set_1. Each process sends an `id`. The agent stores these ids in a dictionary and sends response that ur id has been accepted. Now agent process receives some data from another process (which is some sort of sister process for the agent). This data contains id along with a command which is to be sent by the agent to the process_set_1 through HTTP client over `AF_UNIX` socket, since each process in process_set_1 has a HTTP listening CLI. The process agent sends an HTTP request by recognizing id stored in dictionary to the process_set_1. A service running in the process_set_1 routes this HTTP command to the respective process. Now my problem is the HTTP request which to be sent must go through AF_UNIX socket. I got this solution. class UnixStreamHTTPConnection(httplib.HTTPConnection): def __init__(self, path, host='localhost/rg_cli',port=None, strict=None, timeout=None): httplib.HTTPConnection.__init__(self, host, port=port, strict=strict, timeout=timeout) self.path=path def connect(self): self.sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) self.sock.connect(self.path) But this cannot work since normal socket will not work and thus i thought of `asyncore` module in python. To use asyncore module again i will have to subclass asyncore.dispatcher. This class also contains connect() method. Another problem is I don't know how asyncore module works and thus not able to find a way to mix the work of 1) listening forever, accept the connection, store id and the sock_fd. 2) accept data from the process' agent sister process, retrieve the sock_fd by matching the id in the dictionary and send it through the AF_UNIX socket. Please help since i have already spent 2 days digging it out. Sorry if could explain my problem very well. Thanks, Norah Jones -- https://mail.python.org/mailman/listinfo/python-list
Fwd: Re: Comparisons and sorting of a numeric class....
Original Message Subject:Re: Comparisons and sorting of a numeric class Date: Mon, 26 Jan 2015 05:38:22 -0800 From: Andrew Robinson To: Steven D'Aprano On 01/24/2015 12:27 AM, Steven D'Aprano wrote: Andrew Robinson wrote: But let me explain a bit more why I'm picking on Python: For even if we set the electronic engineering concerns aside that I've raised (and they are valid, as OOP is supposed to model reality, not reality be bent to match OOP) -- People's facile explanations about why Python's version of bool is the way it is -- still bothers me here in the python mail list -- because people seem to have a very wrong idea about bool's nature as a dualton being somehow justified solely by the fact that there are only two values in Boolean logic; Nobody has suggested that except you. Yes, they did 'suggest' it. Earlier I even stated that I didn't know GvR's motivation in making True and False singletons, but suggested that it might have been a matter of efficiency. True... but you are not the only person on this list. Although I seriously doubt that either efficiency, or memory conservation plays a part in this in any meausrable manner. eg: You accused me of 'pre-optimizing' earlier, and if anything looks like a pre-optimization, it's the bool itself because computers have tons of memory now, and I seriously doubt modern Python versions can even run in a small micro-controler; eg: without an almost complete rewrite of the languageand as far as efficiency, I know speed won't change significantly whether or not a singleton, or multiple instances are allowed except under very unusual circumstances. So, even now -- I have no idea why Guido chose to make bool so restrictive other than because he thought C++ was absolutely restrictive, when in fact C++'s type system is more flexible than he seems to have noticed. -- And I know Charles bool didn't use singletons in his algebra, -- just read his work and you'll see he never mentions them or describes them, but he does actually use dozens of instances of the True and False objects he was talking about -- for the obvious reason that he would have needed special mirrors, dichroic or partially silvered, to be even able to attempt to make one instance of True written on paper show up in multiple places; And that's silly to do when there's no compelling reason to do it. In the words of physicist Wolfgang Pauli, that is not even wrong. http://en.wikipedia.org/wiki/Not_even_wrong I'm actually gobsmacked that you could seriously argue that because Boole wrote down true and false (using whatever notation he choose) more than once, that proves that they aren't singletons. That's as sensible as claiming that if I write your name down twice, you must be two people. Clearly: Charles bool did not use singletons, and you are wasting your breath splitting hairs that are moot. Yet -- people here seem to want to insist that the bool type with only two instances is some kind of pure re-creation of what Charles Bool did -- when clearly it isn't. Nobody has argued that Boole (note the spelling of his name) considered True and False to be singletons. Being a mathematician, he probably considered that there is a single unique True value and a single unique False value, in the same way that there is a single unique value pi (3.1415...) and a single unique value 0. The spelling caveat is great -- and in Python the object named in bool's honor is spelled bool (lowercase too). ;) another point about the inconsistency of the object with the historical author, I just love it, which is part of why I'm going to keep on spelling it like that For even the spelling, suggests Python is really acting like a lemming and just doing bool because Guido though other lanugages do bool... so I'll just continue because it's fitting that anyone who mocks my use of the mis-spelling bool also mock's Python's. But "the number of instances" and "singleton" are concepts from object oriented programming, which didn't exist when Boole was alive. Yep -- I made that point myself in an earlier e-mail. Do you feel brilliant, or something, copying my remarks ? It is not even wrong to ask the question whether Boole thought of true and false to be singleton objects. He no more had an opinion on that than Julius Caesar had an opinion on whether the Falkland Islands belong to the UK or Argentina. Oh! So you want people to think you commune with the dead, and know he never thought about it alive and/or dead? D'Aprano speaks posthumously for Dr. bool ? You're being very condescending and arrogant and arguing in pointless circles! I said, and I quote "He didn't use singletons in his algebra" -- if you can show where he did, I'll retract my remark; otherwise -- you're merely proving my point. It's a amalgamation of enhancements such as binary words instead of just True/False and many other things (operators that work on words rathe
Re: Why does argparse return None instead of [] if an append action isn't used?
On 2015-01-09, Wolfgang Maier wrote:
> On 01/09/2015 03:44 PM, Adam Funk wrote:
>> I noticed in use that if an option with the 'append' action isn't
>> used, argparse assigns None to it rather than an empty list, &
>> confirmed this interactively:
>>
>> #v+
> import argparse
> parser = argparse.ArgumentParser()
> parser.add_argument('--foo', action='append')
>> _AppendAction(option_strings=['--foo'], dest='foo', nargs=None, const=None,
>> default=None, type=None, choices=None, help=None, metavar=None)
> parser.add_argument('--bar', action='append')
>> _AppendAction(option_strings=['--bar'], dest='bar', nargs=None, const=None,
>> default=None, type=None, choices=None, help=None, metavar=None)
> parser.parse_args('--foo 1 --foo 2'.split())
>> Namespace(bar=None, foo=['1', '2'])
>> #v-
>>
>
> Isn't that the exact behaviour documented here:
>
> https://docs.python.org/3/library/argparse.html#default
>
> where it says that the default for the default argument is None ?
>
> I think Skip is right: you should be able to just add
>
> default = []
>
> to your arguments in the add_argument call.
Yes, it works.
--
Master Foo said: "A man who mistakes secrets for knowledge is like
a man who, seeking light, hugs a candle so closely that he smothers
it and burns his hand."--- Eric Raymond
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why does argparse return None instead of [] if an append action isn't used?
On 2015-01-09, Ned Batchelder wrote: > On 1/9/15 9:44 AM, Adam Funk wrote: >> This makes it a bit more trouble to use: >> >>if options.bar: >> for b in options:bar >> do_stuff(b) >> >> instead of >> >>for b in options.bar >> do_stuff(b) > > This doesn't answer why the value defaults to None, and some people may > recoil at it, but I've used: > > for b in options.bar or (): > do_stuff(b) Do you mean "for b in options.bar or []:" ? -- War is God's way of teaching Americans geography. [Ambrose Bierce] -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does argparse return None instead of [] if an append action isn't used?
Adam Funk wrote: > On 2015-01-09, Ned Batchelder wrote: > >> On 1/9/15 9:44 AM, Adam Funk wrote: >>> This makes it a bit more trouble to use: >>> >>>if options.bar: >>> for b in options:bar >>> do_stuff(b) >>> >>> instead of >>> >>>for b in options.bar >>> do_stuff(b) >> >> This doesn't answer why the value defaults to None, and some people may >> recoil at it, but I've used: >> >> for b in options.bar or (): >> do_stuff(b) > > Do you mean "for b in options.bar or []:" ? Doesn't matter; in the context of a for loop any empty iterable would do. -- https://mail.python.org/mailman/listinfo/python-list
Re: HTTP over Asynchronous AF_UNIX Socket in python
Norah Jones : > But this cannot work since normal socket will not work and thus i > thought of `asyncore` module in python. To use asyncore module again i > will have to subclass asyncore.dispatcher. This class also contains > connect() method. > > Another problem is I don't know how asyncore module works and thus not > able to find a way to mix the work of 1) listening forever, accept the > connection, store id and the sock_fd. > 2) accept data from the process' agent sister process, retrieve the > sock_fd by matching the id in the dictionary and send it through the > AF_UNIX socket. Asyncore was a nice idea, but you shouldn't build anything on top of it. The newest Python versions have moved to a scheme called asyncio. Its programming model is a bit unconventional and hasn't won me over yet. Personally, I have found select.epoll(EPOLLET) plus a timer implementation enough of a framework for all of my async needs. Then comes HTTP support. The stdlib networking facilities are great for quick scripting, but not really compatible with the asynchronous paradigm. I have coded my protocols by hand myself. Marko -- https://mail.python.org/mailman/listinfo/python-list
PythonFOSDEM 2015 - Last news
Hi all, This week-end is FOSDEM and especially the PythonFOSDEM 2015, PythonFOSDEM will take place in Brussels, in Belgium, in Europe. If you don't know FOSDEM, here is the site https://fosdem.org/2015/ About the PythonFOSDEM, the site http://www.python-fosdem.org/ The last blog post with some pictures of the last edition http://blog.python-fosdem.org/post/109196659496/pythonfosdem-2015-last-news The schedule: http://www.python-fosdem.org/#programme https://fosdem.org/2015/schedule/track/python/ If you don't know what to do this week-end, just take a plane or your car, you won't regret it. Chocolate, Beers, Python developers, Plush snake, Shirts, Books, free eBooks, If you don't know Brussels, this is the most beautiful place of Europe and maybe of the world. Bye and See you there with the Python Community. Cheers, Stephane -- Stéphane Wirtel - http://wirtel.be - @matrixise -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On Thu, Jan 22, 2015, at 23:23, Steven D'Aprano wrote: > Rick Johnson wrote: > > > The solution is move the type > > hinting syntax completely out of the source file and into > > another file -- think of it as a "Python Type Hinting Header > > File". > > The 1970s called, they want their bad ideas back. > > I can do no better than to quote from the Go FAQs: > > Dependency management is a big part of software development > today but the “header files” of languages in the C tradition > are antithetical to clean dependency analysis—and fast > compilation. This is more along the lines of a lint library than a header file (header files in the 1970s didn't even actually include function signature information) - which did not even participate in compilation at all. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does argparse return None instead of [] if an append action isn't used?
On 2015-01-26, Peter Otten wrote: > Adam Funk wrote: > >> On 2015-01-09, Ned Batchelder wrote: >> >>> On 1/9/15 9:44 AM, Adam Funk wrote: This makes it a bit more trouble to use: if options.bar: for b in options:bar do_stuff(b) instead of for b in options.bar do_stuff(b) >>> >>> This doesn't answer why the value defaults to None, and some people may >>> recoil at it, but I've used: >>> >>> for b in options.bar or (): >>> do_stuff(b) >> >> Do you mean "for b in options.bar or []:" ? > > Doesn't matter; in the context of a for loop any empty iterable would do. Of course it would. Doh! -- A recent study conducted by Harvard University found that the average American walks about 900 miles a year. Another study by the AMA found that Americans drink, on average, 22 gallons of alcohol a year. This means, on average, Americans get about 41 miles to the gallon. http://www.cartalk.com/content/average-americans-mpg -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does argparse return None instead of [] if an append action isn't used?
On Mon, Jan 26, 2015 at 8:50 AM, Adam Funk wrote: > On 2015-01-26, Peter Otten wrote: > >> Adam Funk wrote: >> >>> On 2015-01-09, Ned Batchelder wrote: for b in options.bar or (): do_stuff(b) >>> >>> Do you mean "for b in options.bar or []:" ? >> >> Doesn't matter; in the context of a for loop any empty iterable would do. > > Of course it would. Doh! Stylistically, I generally prefer the empty list for this. The empty tuple might be a little faster since it's a singleton and doesn't need to be constructed at runtime, but that's clearly a micro-optimization, and I think the list more accurately conveys the intention of "something to be iterated over". Although tuples are iterable, I don't often use them for that purpose. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does argparse return None instead of [] if an append action isn't used?
Ian Kelly writes: > On Mon, Jan 26, 2015 at 8:50 AM, Adam Funk wrote: > > On 2015-01-26, Peter Otten wrote: > > > >> Adam Funk wrote: > >> > >>> On 2015-01-09, Ned Batchelder wrote: > for b in options.bar or (): > do_stuff(b) > >>> > >>> Do you mean "for b in options.bar or []:" ? > >> > >> Doesn't matter; in the context of a for loop any empty iterable > >> would do. > > > > Of course it would. Doh! > > Stylistically, I generally prefer the empty list for this. The empty > tuple might be a little faster since it's a singleton and doesn't > need to be constructed at runtime, but that's clearly a > micro-optimization, and I think the list more accurately conveys the > intention of "something to be iterated over". Although tuples are > iterable, I don't often use them for that purpose. I've used tuples to convey the intention of immutability, as opposed to using lists. For all I know, collecting a generator (from groupby) into a tuple might be slower than collecting it into a list. I have no intention to measure this. The programs have been fast enough for me. -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Re: Comparisons and sorting of a numeric class....
On 26/01/2015 13:38, Andrew Robinson wrote: *plonk* -- 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: Python is DOOMED! Again!
[Reposting. First attempt went direct to poster, perhaps via email, not sure why as I don't have a button to do that. If this does the same then please ignore.] On 23/01/2015 10:59, Steven D'Aprano wrote: > Chris Angelico wrote: > >> On Fri, Jan 23, 2015 at 1:16 AM, Steven D'Aprano >> wrote: >>> Mario Figueiredo wrote: >>> def handle_employees(emp: Union[Employee, Sequence[Employee]], raise: Union[float, Sequence[float]]) -> Union[Employee, Sequence[Employee], None]: >>> >>> Using >>> floats for money is Just Wrong and anyone who does so should have their >>> licence to program taken away. >> >> But using a float to specify a percentage raise that an employee (or >> class of employees) gets would be reasonable. > > I don't think that a raise of 0.10001 (10%), > 0.035003 (3.5%) or 0.070007 (7%) is quite what > people intended. It seems they are getting a bigger raise than they expected in each case. So why complain? But in practice they will never see that billionth of a cent extra; they will get the same amount as they would if floating point wasn't used. And, how is the increase determined? It could well be the result of some complex calculation performed in floating point, which then has to be converted to ... BTW how *do* you represent a raise of 10% exactly if not with binary floating point? -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does argparse return None instead of [] if an append action isn't used?
On 26/01/2015 16:29, Jussi Piitulainen wrote: I've used tuples to convey the intention of immutability, as opposed to using lists. For all I know, collecting a generator (from groupby) into a tuple might be slower than collecting it into a list. I have no intention to measure this. The programs have been fast enough for me. IIRC, and probably from this list, creating tuples is way faster than creating lists, but accessing items is slower. Can anybody confirm this for us? -- 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: HTTP over Asynchronous AF_UNIX Socket in python
On 01/26/2015 06:32 AM, Norah Jones wrote: > Now my problem is the HTTP request which to be sent must go through > AF_UNIX socket. The Python Twisted framework may be of use to you. It's got a very steep learning curve, but it's fairly easy to change the underlying byte transport for any protocol they have implemented. In fact in the Twisted docs, they show a web client accessing an HTTP server over a unix socket (scroll down to the bottom of the page): http://twisted.readthedocs.org/en/latest/web/howto/client.html They show a client connecting to a Docker server which is speaking HTTP over a unix socket. Twisted is very powerful and flexible, and event-driven. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python simple Code
On Saturday, January 24, 2015 at 4:16:27 PM UTC-8, Salem Alqahtani wrote: > Hi Guys, > > I just joined the group and I hope that I can help and be active. > > I have a question about python. I wrote a code on python 2.7 and I want to > choose from the list of names that I provide n!. I execute the code but the > result or output is the numbers. I want the people names are the result. > > > Sincerely > > import sys > import array > a=['salem','Ali','sultan'] > m = len(a) > def Factorials(m): > if m == 0: > return 1 > else: > print m > return m * Factorials(m-1) > def output(): > print a > def main(): > print Factorials(m) > output() > main() Your English is a bit rough, but from what I'm understanding, the output you're TRYING to get is: salem Ali sultan If that's the case, then why do you have functions using factorials? It sounds like you really have no idea what you're doing and just blindly copied some other code with zero understanding of it. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does argparse return None instead of [] if an append action isn't used?
On Mon, Jan 26, 2015 at 10:18 AM, Mark Lawrence wrote: > IIRC, and probably from this list, creating tuples is way faster than > creating lists, but accessing items is slower. Can anybody confirm this for > us? The first seems to be true as long as the tuples are small. $ python3 -m timeit 't = (1000, 2000, 3000)' 1 loops, best of 3: 0.0147 usec per loop $ python3 -m timeit 't = [1000, 2000, 3000]' 1000 loops, best of 3: 0.0678 usec per loop $ python3 -m timeit 't = tuple(range(1))' 1 loops, best of 3: 183 usec per loop $ python3 -m timeit 't = list(range(1))' 1 loops, best of 3: 174 usec per loop $ python3 -m timeit 't = tuple(range(1000))' 10 loops, best of 3: 323 msec per loop $ python3 -m timeit 't = list(range(1000))' 10 loops, best of 3: 306 msec per loop This is probably a result of the use of freelists to avoid reallocating the tuple objects, though. I don't see any substantial difference in access time: $ python3 -m timeit -s 't = tuple(range(1))' 't[5000]' 1000 loops, best of 3: 0.0316 usec per loop $ python3 -m timeit -s 't = list(range(1))' 't[5000]' 1000 loops, best of 3: 0.0318 usec per loop $ python3 -m timeit -s 't = tuple(range(1))' 'for x in t: pass' 1 loops, best of 3: 112 usec per loop $ python3 -m timeit -s 't = list(range(1))' 'for x in t: pass' 1 loops, best of 3: 113 usec per loop -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does argparse return None instead of [] if an append action isn't used?
On Mon, Jan 26, 2015 at 11:23 AM, Ian Kelly wrote: > $ python3 -m timeit 't = (1000, 2000, 3000)' > 1 loops, best of 3: 0.0147 usec per loop > $ python3 -m timeit 't = [1000, 2000, 3000]' > 1000 loops, best of 3: 0.0678 usec per loop > $ python3 -m timeit 't = tuple(range(1))' > 1 loops, best of 3: 183 usec per loop > $ python3 -m timeit 't = list(range(1))' > 1 loops, best of 3: 174 usec per loop > $ python3 -m timeit 't = tuple(range(1000))' > 10 loops, best of 3: 323 msec per loop > $ python3 -m timeit 't = list(range(1000))' > 10 loops, best of 3: 306 msec per loop > > This is probably a result of the use of freelists to avoid > reallocating the tuple objects, though. I don't see any substantial > difference in access time: Whoops. Actually it's a result of the 3-element tuple being a constant in the code object. If we use the constructor, the difference mostly goes away. $ python3 -m timeit 't = tuple(range(1000, 4000, 1000))' 100 loops, best of 3: 0.559 usec per loop $ python3 -m timeit 't = list(range(1000, 4000, 1000))' 100 loops, best of 3: 0.585 usec per loop -- https://mail.python.org/mailman/listinfo/python-list
Running a .py file iteratively at the terminal
Hello Everyone, I am running a python script as of now and I have to change three global values repeatedly. I'm tired of doing this manually. SO, I was wondering if there is a way to run a python command repeatedly. In my case, the command would be srva@hades:~$ python NFV_v3_7_10_14.py -l log --lp --xml eu_v3_14_1_15.xml Everytime I run this, I get a log file with the results. The main file is the NFV_v3py. These are the values I intend to change iteratively and then run the command in the terminal. dataplane_latencybound = 200 # The delay bounds are in milli seconds controlplane_latencybound1 = 200 # The delay bounds are in milli seconds So, in every iteration, I would like to increase it from 0 in steps of 10 till 200. And after doing so, I'd like to run the command. But, I'm unaware of doing this using a single script. I hope some of you experts over there could help me in this issue. It can be a huge timesaver. Thanks a lot guys Varun RS -- https://mail.python.org/mailman/listinfo/python-list
Re: What killed Smalltalk could kill Python
On 01/23/2015 04:57 PM, Chris Angelico wrote: > On Sat, Jan 24, 2015 at 9:51 AM, Tim Daneliuk wrote: >> On 01/21/2015 05:55 PM, Chris Angelico wrote: >>> On Thu, Jan 22, 2015 at 10:37 AM, Tim Daneliuk >>> wrote: I find these kinds of discussions sort of silly. Once there is a critical mass of installed base, no language EVER dies. >>> >>> Not sure about that. Back in the 1990s, I wrote most of my code in >>> REXX, either command-line or using a GUI toolkit like VX-REXX. Where's >>> REXX today? Well, let's see. It's still the native-ish language of >>> OS/2. Where's OS/2 today? Left behind. REXX has no Unicode support (it >>> does, however, support DBCS - useful, no?), no inbuilt networking >>> support (there are third-party TCP/IP socket libraries for OS/2 REXX, >>> but I don't know that other REXX implementations have socket services; >>> and that's just basic BSD sockets, no higher-level protocol handling >>> at all), etc, etc. Sure, it's not technically dead... but is anyone >>> developing the language further? I don't think so. Is new REXX code >>> being written? Not a lot. Yet when OS/2 was more popular, REXX >>> definitely had its installed base. It was the one obvious scripting >>> language for any OS/2 program. Languages can definitely die, or at >>> least be so left behind that they may as well be dead. >>> >>> ChrisA >>> >> >> Rexx is still well used on mainframes. > > Oh, is it? Cool! Maybe some day I'll be interviewing for a job, and > they'll ask if I know REXX.. and I'll actually be able to say yes. :) > > ChrisA > Let me first note for the record that I make my living on *NIX type systems. So, my comments below are not bound to my personal technical religion ... I work in and among some of the larger corporations on the planet and I have a little secret for you: Mainframes are NOT going away wholesale. As the population of mainframe-savvy staff dwindles into retirement, one of the hottest tickets you're going to see in the next 20 years is people who can do that work. It's so bad, that IBM themselves are working to train the next generation of MVS systems programmers, and the like. And no, you can't just replace mainframes with open systems equivalents. There are likely hundreds of millions of lines of COBOL and assembler code that cannot just be ported over to a new platform and language. Why? Because there is an ecosystem of support in the mainframe world that is utterly absent in the *NIX/Windoze world. This includes things especially like CICS, IMS (ask Caterpillar if they'll stop using it ;), DB2 and so forth. So, yes, if you're mainframe savvy, you may have a nice consulting career in your old age :) -- Tim Daneliuk [email protected] PGP Key: http://www.tundraware.com/PGP/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Re: Comparisons and sorting of a numeric class....
Hi Mark ! I hope you are well, and haven't been injured falling out of your chair laughing. There are probably 12 to 14 emails that I haven't been able to read in my inbox from the python list on the subject of this 'drivel', because I have a real life besides the semi-comedy act that goes on here. I seriously doubt I will ever read them all... On 01/26/2015 08:31 AM, Mark Lawrence wrote: On 26/01/2015 13:38, Andrew Robinson wrote: *plonk* Ah well, now that I have actually bothered to read your three replies, I suppose the most surprising part of your emails is this: -My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. You do realize that such a statement actually encourages more drivel ? :D Cheers. -- https://mail.python.org/mailman/listinfo/python-list
Re: Running a .py file iteratively at the terminal
On 26/01/2015 19:52, [email protected] wrote: Hello Everyone, I am running a python script as of now and I have to change three global values repeatedly. I'm tired of doing this manually. SO, I was wondering if there is a way to run a python command repeatedly. In my case, the command would be srva@hades:~$ python NFV_v3_7_10_14.py -l log --lp --xml eu_v3_14_1_15.xml Everytime I run this, I get a log file with the results. The main file is the NFV_v3py. These are the values I intend to change iteratively and then run the command in the terminal. dataplane_latencybound = 200 # The delay bounds are in milli seconds controlplane_latencybound1 = 200 # The delay bounds are in milli seconds So, in every iteration, I would like to increase it from 0 in steps of 10 till 200. And after doing so, I'd like to run the command. But, I'm unaware of doing this using a single script. I hope some of you experts over there could help me in this issue. It can be a huge timesaver. Thanks a lot guys Varun RS I think you need this:- dataplane_latencybound in range(0, 205, 10): doSomething(dataplane_latencybound) -- 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: Running a .py file iteratively at the terminal
Thanks a lot Mark but that would be a bit trivial. How can I run the same file multiple times? Or if I need to run two commands: srva@hades:~$ python NFV_nw_eu_v3_14_1_15.py --output eu_v3_14_1_15 --demand demands_v3_21_1_15.xml --xml nobel-eu.xml srva@hades:~$ python NFV_v3_7_10_14.py -l log --lp --xml eu_v3_14_1_15.xml repeatedly, how can I do that? Can I write a script to perform this function?If so, can you please help me with it? The first command generates an output file eu_v3 and the second file feeds it to the solver. This is what I intend to do multiple times. I hope I have explained it this time in a much better way. I'm sorry English is my second language and I have some problems in expressing myself at times. Thank You -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Re: Comparisons and sorting of a numeric class....
On Jan 26, 2015 6:42 AM, "Andrew Robinson" wrote: > ... If you're going to descend into insults and name-calling, then I'm not going to waste any more of my time on this thread. The restriction on inheriting from bool isn't likely to change. There have been several suggestions as to how you can do what you want. I recommend you pick one and get on with it. -- https://mail.python.org/mailman/listinfo/python-list
Re: Running a .py file iteratively at the terminal
On 26Jan2015 13:10, [email protected] wrote: Thanks a lot Mark but that would be a bit trivial. How can I run the same file multiple times? Or if I need to run two commands: srva@hades:~$ python NFV_nw_eu_v3_14_1_15.py --output eu_v3_14_1_15 --demand demands_v3_21_1_15.xml --xml nobel-eu.xml srva@hades:~$ python NFV_v3_7_10_14.py -l log --lp --xml eu_v3_14_1_15.xml repeatedly, how can I do that? Can I write a script to perform this function?If so, can you please help me with it? The first command generates an output file eu_v3 and the second file feeds it to the solver. This is what I intend to do multiple times. I hope I have explained it this time in a much better way. I'm sorry English is my second language and I have some problems in expressing myself at times. Certainly you can script it. Write a tiny shell script (named "mygensolve.sh" for the sake of example). Example (untested): #!/bin/sh python NFV_nw_eu_v3_14_1_15.py --output eu_v3_14_1_15 --demand demands_v3_21_1_15.xml --xml nobel-eu.xml python NFV_v3_7_10_14.py -l log --lp --xml eu_v3_14_1_15.xml Either make it executable ("chmod +rx mygensolve.sh") and run it like this: ./mygensolve.sh or don't bother, and run it in an analogous fashion to your python commands: sh mygensolve.sh There are multiple paths forward from here if you have many runs with filenames which can be enurated somehow. Cheers, Cameron Simpson The top three answers: Yes I *am* going to a fire! Oh! We're using *kilometers* per hour now. I have to go that fast to get back to my own time. - Peter Harper -- https://mail.python.org/mailman/listinfo/python-list
Re: Comparisons and sorting of a numeric class....
Hi, Rob. Sorry I'm so slow in getting back to you there's too much to read and I can't catch up with the backlog. But I wanted to reply to you, at least as I think you made some very good points that make more sense to me than other people's replies. On 01/15/2015 09:54 AM, Rob Gaddi wrote: On Wed, 14 Jan 2015 23:23:54 -0800 Andrew Robinson wrote: Boolean algebra has two values: true and false, or 1 and 0, or humpty and dumpty, or whatever you like to call them. You're speaking to an Electrical engineer. I know there are 10 kinds of people, those who know binary and those who don't. But you're way off base if you think most industrial quality code for manipulating boolean logic uses (or even can be restricted to use) only two values and still accomplish their tasks correctly and within a finite amount of time. [snip] Absolutely it does and can. You store anything that's non-boolean in a non-boolean value, and keep it as fuzzy as you like. But at the end of the day, an if statement has no "kinda". You do, or you don't. 1 or 0. And so you must ultimately resolve to a Boolean decision. Yes -- at the *point* of decision; a logic expression always collapses to a True or False value. metastability must always resolve to a final value, or else the system will malfunction. (Although cache branch prediction can choose to take both paths, one of them eventually gets flushed). That's the same in digital circuitry as well, even with uncertainty meta information appended to it. You have to ask if x = '1' or if (x = '1') or (x = 'H') Because you are comparing one value of an enumerated type against others, the result of that '=' operation being, in fact, a boolean, defined again on the range (true, false). That's fine, too. An enumerated type is still a semantic subtype, if not a formal one recognized by type(). So -- I don't see that you are arguing the two types must be semantically distinct until the if statement is actually executed, at which point a true/false decision must be made. I totally agree, digital systems must make a final decision at some point. Your example, here, BTW: is almost exactly what I was talking about in the original few posts of the thread; Eg: a way to comparing the uncertainty value returned by a float's subtype's compare -- against an enumerated bool meta-type to resolve that value to a final True or False for an if statement. [snip] We've discovered that we live in a quantum-mechanical universe -- yet people still don't grasp the pragmatic issue that basic logic can be indeterminate at least some of the time ?! But actions can't be. You're not asking the software about it's feelings, you're telling it to follow a defined sequence of instructions. Do this, or don't do this. Right! And, in quantum mechanics -- a wave packet 'collapses' to one and only one final decision. So, I agree with you; and let me get your opinion: I admit, there can be good reasons to prevent direct subtyping; I know, for example, that in C++ no base class is allowed to be subtyped -- but not because of OOP concerns or ideology about bool; I'm fairly sure the reason had something to do with difficulties in implementing base class overloading in the compiler due to compile time binding issues. But that's useless reasoning with an interpreter like Python which *already* allows subtyping of at least some base classes and does runtime type() tests instead of compile time tests. So: The major question I have been asking about is 'when' must the decision be made, and 'why' (besides oversight / copying other languages) is the a bool variable/object in Python designed in such a way as to force the decision to be made early, rather than late -- and prevent bool from carrying extended information about the bool itself; eg: meta information -- so that the final decision can be delayed until an 'if' statement is actually used, and the context is known: eg: x = a > b # x is an uncertain compare that generates meta data along with a boolean True or False. # this value 'x' can be used in two ways: if x > bool_meta_threshold: # if statement's branch chosen by meta data. if x: # If statement's branch chosen by default/base bool value contained in x, meta data is ignored. I don't know what you mean about composition vs. sub-classing. Would you care to show an example of how it would solve the problem and still allow hierarchical sorting ? I don't see how you can get pre-existing python functions (like sort, max, and min) to accept a complex bool value and have that value automatically revert to a True or False in an intelligent manner without overloading the operators defined in some class -- somewhere -- to operate on the data the class contains. How do you intend to achieve that with this -- composition -- thing you mentioned ? You'd do it something like this. class _clogic(object): """Represents 'continuou
Re: Python is DOOMED! Again!
[email protected] wrote: > On Thu, Jan 22, 2015, at 23:23, Steven D'Aprano wrote: >> Rick Johnson wrote: >> >> > The solution is move the type >> > hinting syntax completely out of the source file and into >> > another file -- think of it as a "Python Type Hinting Header >> > File". >> >> The 1970s called, they want their bad ideas back. >> >> I can do no better than to quote from the Go FAQs: >> >> Dependency management is a big part of software development >> today but the “header files” of languages in the C tradition >> are antithetical to clean dependency analysis—and fast >> compilation. > > This is more along the lines of a lint library than a header file Stub files are a second-rate solution for the problem of annotating functions where you are unable (or unwilling) to annotate the source code directly. They suffer from similar problems: - you have to manage the stub file independently of the source code it belongs with - type information is about as far away from the variable as it is possible to get (a completely different file!) - lexical analysis has to look for twice as many files (it has to hit the hard drive for a stub file before looking at the source), and we know from importing that file system access is a significant and expensive part of the process. But, when the first-rate solution cannot be used, a second-rate solution is better than nothing. > (header files in the 1970s didn't even actually include function > signature information) - which did not even participate in compilation > at all. If C compilers didn't use the header files, what were they for? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
BartC wrote:
> how do you represent a raise of 10% exactly if
> not with binary floating point?
In Python today, the best solution is probably to use Decimals:
from decimal import Decimal
raise = Decimal("0.1")
But the traditional solution is to track money in cents, or a fixed fraction
of a cent, using integers, and do everything in integer maths. That has the
disadvantage that division always truncates, but if you care about that you
can easily write your own division-with-round-to-nearest function.
Or use Decimal, which handles rounding correctly and flexibly.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On Tue, 27 Jan 2015 11:11:45 +1100, Steven D'Aprano wrote: > [email protected] wrote: >> (header files in the 1970s didn't even actually include function >> signature information) - which did not even participate in >> compilation at all. > If C compilers didn't use the header files, what were they for? The compiler did use the header files, but only for functions' return types and other non-function-signature things (like macros and type definitions). Dan -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On Monday, January 26, 2015 at 6:12:00 PM UTC-6, Steven D'Aprano wrote: > Stub files are a second-rate solution for the problem of > annotating functions where you are unable (or unwilling) > to annotate the source code directly. They suffer from > similar problems: > > - you have to manage the stub file independently of the > source code it belongs with > > - type information is about as far away from the variable as it > is possible to get (a completely different file!) > > - lexical analysis has to look for twice as many files (it has to > hit the hard drive for a stub file before looking at the source), > and we know from importing that file system access is a > significant and expensive part of the process. Funny how your example logically leads to the solution of your own "partisan problem". At an early stage in the design process, most wise designers would realize that: since stub files are optional, and therefore searching for stub files *EVERY TIME* Python is reading a script is superfluous, then the solution is to require a declaration in every file that wants typehinting. In other words, put the onerous on the "typehint author" by requiring a "typehint declaration" at the top of every file that has a corresponding typehints stub. usestypehints scriptA.typehints Of course, there are much better alternatives than to introduce *another* keyword. Shebangs, strings, whatever So don't take my example too literally! > But, when the first-rate solution cannot be used, a > second-rate solution is better than nothing. Your synthetic "first rate vs second rate" dichotomy is nothing more than a highly subjective and one sided interpretation meant to paint the opposition as wrong without offering any real evidence of "wrongfulness". Are you attempting to polarize this issue? And if you are, what possible good could come from injecting emotion into a technical debate? To find truths one must remain open to new ideas, *only* follow logical paths, and *defiantly* reject the corrupting influence of emotion. Does impartiality mean *anything* to you? Have you ever wondered why lady justice wears a blindfold? -- https://mail.python.org/mailman/listinfo/python-list
Re: Comparisons and sorting of a numeric class....
On Mon, Jan 26, 2015 at 4:47 PM, Andrew Robinson wrote: > Hmmm That's not much different than the tuple object I made as a > container and which Ian complained about. In fact, you did overload the > comparison operators, just like I did... Yeah, I know I said I was done with this thread, but since you call me out by name I'll take a moment to respond. > Let's see: Ian first complained that I wasn't subclassing in one example, No. What I suggested was that for Python 2 you should explicitly name a base class of object, i.e. the base class of *everything*. That's not "you should use subclassing here", but rather "here's a tip for writing good, Pythonic code". > and then he next complained that he thought I was subclassing *too quickly* > (like he forgot that I didn't subclass before) because of something to do > with 'bool' -- and then he mentioned I wasn't using composition I actually wrote about your tuple subclass "This seems fine," so don't try to spin my words into something that they aren't. My criticism was centered on your needless subclassing of tuple (nothing to do with 'bool'), resulting in a boolean class that supports nonsensical operations like: >>> len(MostlyFalse) 2 and even: >>> isinstance(MostlyFalse, Sequence) True You may also notice that Rob's example which you compare to your own doesn't do this. > But now --I wonder why it didn't click with him that I avoided subclassing > bool in my tuple example (at all) -- because I was clearly making a general > purpose container (composition pattern) to hold a bool and uncertainty > value. This is not an example of composition. By subclassing tuple, you are effectively declaring that your boolean type IS a type of tuple. Instead of aggressively and arrogantly defending poor code, why don't you take my criticism as the learning opportunity that it was offered as? Here would be a good place to start: http://stackoverflow.com/questions/49002/prefer-composition-over-inheritance -- https://mail.python.org/mailman/listinfo/python-list
Re: Python simple Code
On Saturday, January 24, 2015 at 6:38:50 PM UTC-6, Denis McMahon wrote: > Observations: > > a) There is no need to import array, you are only using a list. I'm just pondering here... (and pinky, i'm looking at you!), but there "may" be a good excuse for "import array". I have a feeling it's merely an artifact. Maybe the OP began his script with a Python array, then realizing he needed a mixed- type container, began using list and forgot to edit his imports. So yes: superfluous, yet forgivable. *HOWEVER* I cannot forgive someone for creating a function that merely prints a global variable! WTH??? @OP: Why did you create the "output" function? -- https://mail.python.org/mailman/listinfo/python-list
unicode question
Hi there python staff does python support arabic language for texts ? and what to do if it support it? i wrote hello in Arabic using codeskulptor and the powershell just for testing and the same error appeared( a sytanx error in unicode)!! -- https://mail.python.org/mailman/listinfo/python-list
Re: unicode question
On Tue, Jan 27, 2015 at 4:17 PM, Rehab Habeeb wrote: > Hi there python staff > does python support arabic language for texts ? and what to do if it support > it? > i wrote hello in Arabic using codeskulptor and the powershell just for > testing and the same error appeared( a sytanx error in unicode)!! If you're using Python 3, you have very good support for non-ASCII text, including Arabic. In Python 2, you can work with Unicode data, but your variable/function names all have to be in ASCII. What was your code, and what was the error? Copy and paste them into the email, and we'll be better able to help you. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On Mon, 26 Jan 2015 17:10:18 -0800, Rick Johnson wrote: > On Monday, January 26, 2015 at 6:12:00 PM UTC-6, Steven D'Aprano wrote: > >> Stub files are a second-rate solution for the problem of annotating >> functions where you are unable (or unwilling) to annotate the source >> code directly. They suffer from similar problems: >> >> - you have to manage the stub file independently of the source code it >> belongs with >> >> - type information is about as far away from the variable as it >> is possible to get (a completely different file!) >> >> - lexical analysis has to look for twice as many files (it has to >> hit the hard drive for a stub file before looking at the source), and >> we know from importing that file system access is a significant and >> expensive part of the process. > > Funny how your example logically leads to the solution of your own > "partisan problem". > > At an early stage in the design process, most wise designers would > realize that: since stub files are optional, and therefore searching for > stub files *EVERY TIME* Python is reading a script is superfluous, then > the solution is to require a declaration in every file that wants > typehinting. In other words, put the onerous on the "typehint author" by > requiring a "typehint declaration" at the top of every file that has a > corresponding typehints stub. Unfortunately that doesn't work. Stubs will be needed for extension modules written in C (or some other language), or built-in modules such as sys (which are built into the interpreter). So modules which will need your declaration won't have anywhere to put it! Likewise for byte-code only libraries (no source code distributed, just the .pyc files). And it does nothing to solve the problem that the type declaration is as far away from the parameters as it is possible to be. [...] >> But, when the first-rate solution cannot be used, a second-rate >> solution is better than nothing. > > Your synthetic "first rate vs second rate" dichotomy I'm sure that there are worse solutions that stub/header files. But splitting information about a single function over two files is by any standard sub-optimal. > is nothing more > than a highly subjective and one sided interpretation Just because I have considered and rejected your solution doesn't mean I haven't given it the thought it deserves. Rick, I'll admit that I was being a smart arse with my quip about the seventies wanting their bad ideas back. A separate header file is a reasonable solution to the problem of type hinting when you cannot or will not annotate the actual source. That makes it "bad" merely in a relative sense: it has serious disadvantages compared to in-place annotations, but it is still a workable solution when you can't annotate the source. Analogy: a spoon makes a really poor knife, but if you have nothing else on hand, you can cut vegetables and even the softer cuts of meat using the side of a spoon. > meant to paint the > opposition as wrong without offering any real evidence of > "wrongfulness". Rick, you just quoted me giving three reasons why stub files are less suitable than in-place annotations. How can you justify claiming that I'm not giving evidence of wrongfulness? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
Dan Sommers wrote: > On Tue, 27 Jan 2015 11:11:45 +1100, Steven D'Aprano wrote: > >> [email protected] wrote: > >>> (header files in the 1970s didn't even actually include function >>> signature information) - which did not even participate in >>> compilation at all. > >> If C compilers didn't use the header files, what were they for? > > The compiler did use the header files, but only for functions' return > types and other non-function-signature things (like macros and type > definitions). I consider return type to be part of the function signature. The signature of a function is the parameters it accepts and the result it returns. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
