Unable to make http request to django server using twisted.web.client.AGENT
I have written a basic tcp server factory, server client and a service using
twisted. The tcp server acts as the middleware between a django server and an
another program (let's call it client program).
What I want to achieve -
1.client requests the middleware tcp server;
2.it sends a string as the request body;
3.the middleware tcp server deserializes information from the request.
4.middleware furthers the serialized information to the django server.
5.The django server then responds to the middleware server which furthers the
response to the client after serializing the response.
I am able to reach till step 3, but am unable to make any http request to the
django server.
The following is my middleware.py
from twisted.internet.protocol import ServerFactory
from twisted.internet.protocol import Protocol
from test_service import MyService
class TCPServerProtocol(Protocol):
data = ''
def connectionMade(self):
self.deferred = self.factory.service.deferred
self.deferred.addCallback(self.factory.service.s)
self.deferred.addCallback(self.transport.write)
self.deferred.addBoth(lambda r: self.transport.loseConnection)
def dataReceived(self, data):
self.data += data
def connectionLost(self, reason):
self.forward(self.data)
def forward(self, data):
if self.deferred is not None:
d, self.deferred = self.deferred, None
d.callback(data)
class TCPServerFactory(ServerFactory):
protocol = TCPServerProtocol
def __init__(self, service):
self.service = service
def runserver(ip, port):
iface = {'home': '192.168.0.104', 'work': '127.0.0.1'}
service = MyService()
factory = TCPServerFactory(service)
from twisted.internet import reactor
reactor.listenTCP(port=port, factory=factory, interface=iface[ip])
reactor.run()
if __name__ == '__main__':
import sys
ip = sys.argv[1]
port = int(sys.argv[2])
runserver(ip, port)
The following is test_service.py
from twisted.internet.defer import Deferred
from test_http_client import HTTPClientFactory
class MyService(object):
def __init__(self):
self.deferred = Deferred()
def s(self, data):
kwargs = {}
kwargs['url'] = b'http://127.0.0.1:8000/some/end/point'
kwargs['url'] = kwargs['url'].encode('latin-1')
kwargs['method'] = 'POST'
kwargs['data'] = data
client = HTTPClientFactory(**kwargs)
d = client.deferred
return d
The following is test_http_client.py
from StringIO import StringIO
import json
from twisted.internet.protocol import Protocol
from twisted.internet.defer import Deferred
from twisted.web.client import Agent, FileBodyProducer
from twisted.web.http_headers import Headers
class HTTPClientProtocol(Protocol):
def __init__(self, finished):
self.finished = finished
self.data = ''
def dataReceived(self, data):
print '--Data Received by HTTPClientProtocol--'
print data
self.data += data
def connectionLost(self, reason):
print '--HTTP Client connection Lost--'
print reason.getErrorMessage()
if self.finished is not None:
print 'finished is not None'
f, self.finished = self.finished, None
f.callback(self.data)
class HTTPClientFactory(object):
"""
Class handling communication with HTTP server.
"""
def __init__(self, **kwargs):
data = kwargs['data']
try:
body = FileBodyProducer(StringIO(json.dumps(data)))
print '--Request body object created--'
except Exception as e:
print '--Request body object creation FAILURE--'
print e
return e
url = kwargs.get('url', None)
method = kwargs.get('method', None)
from twisted.internet import reactor
agent = Agent(reactor)
if not data:
body = None
self.deferred = agent.request(method,
url,
Headers({'Content-Type':
['application/json']}),
bodyProducer=body)
self.deferred.addCallback(self.get_response)
def get_response(self, response):
print 'Response received'
finished = Deferred()
response.deliverBody(HTTPClientProtocol(finished))
return finished
--
https://mail.python.org/mailman/listinfo/python-list
Re: What does “grep” stand for?
Am 05.11.15 um 01:42 schrieb Chris Angelico: On Thu, Nov 5, 2015 at 6:38 AM, Christian Gollwitzer wrote: As someone who grew up on MS-DOS, I'd like to mention that EDLIN's value wasn't in the obvious places. There were two features it had that most other editors didn't: firstly, it would read only as much of the file as it needed, so you could edit a file larger than available memory; and secondly, all commands came from stdin, which could be redirected - making it a poor man's 'sed'. Using EDLIN for regular file editing was never the normal thing. I also grew up with MSDOS, albeit some later version (3.0 was the first, I think I remember). I knew that EDLIN existed, but never ever have used it. On my first "own" (actually my father's) machine, the Amstrad PC1512, there was a preinstalled GUI working environment called GEM from Digital Research. The DOS commandline was used for configuring and booting the system, but never for editing files. I had used copy con: to create a file. If I'm not mistaken, DR shipped some "visual" editor for DOS with it as an addition. The point I'm so amused is, that MS has not felt the need to ship a real editor, and also cut back on most of the other tools that make computing, even on commandlines, a pleasant experience. Readline? Tab-Completion? I read a magazine called "DOS", where they scripted the hell out of .BAT-files. When they first showed an article about bash programming, I was really jealous that the people on these strange, exotic OSes had such a complete programming language at their disposal. Now I can't imagine giving it back ever. Fast forward a decade or two, and I'm working on a MUD server for a friend. It incorporates an editor that can be used on a dumb telnet connection - and it's line based again. So there's clearly some value here :) Visual editors get the lion's share of actual editing work, but in special circumstances, it is nice to have a quick little ed-like program around. In this case I'd copy the file to the local machine and sync it using rsync or git. It's almost as terse in terms of bandwidth as the manual editing commands, but a lot more comfortable. Christian -- https://mail.python.org/mailman/listinfo/python-list
Re: Detection of a specific sound
Joel Goldstick wrote: Sometimes (maybe most times) the follow on discussion goes off on insightful tangents that may have little to do with the OP. And then someone mentions a Monty Python sketch about Hitler, thereby both bring the discussion back on-topic *and* invoking Godwin's Law at the same time. Don't-mention-the-war-ly, Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Regular expressions
On Wednesday, November 4, 2015 at 7:46:24 PM UTC-7, Chris Angelico wrote: > On Thu, Nov 5, 2015 at 11:24 AM, rurpy wrote: > The "take away" that I recommend is: Rurpy loves to argue in favour of > regular expressions, No, I don't love it, I quite dislike it. > but as you can see from the other posts, there > are alternatives, which are often FAR superior. No, not FAR superior, just preferable and just in the simple cases, regexes generally being better in anything beyond simple. -- https://mail.python.org/mailman/listinfo/python-list
Re: Regular expressions
On 11/04/2015 07:24 PM, Steven D'Aprano wrote: > On Thu, 5 Nov 2015 11:24 am, wrote: > >> You will find they are an indispensable tool, not just in Python >> programming but in many aspects of computer use. > > You will find them a useful tool, but not indispensable by any means. > > Hint: > > - How many languages make arithmetic a built-in part of the language? Almost > all of them. I don't know of any language that doesn't let you express > something like "1 + 1" using built-in functions or syntax. Arithmetic is > much closer to indispensable. By my count there are 2377. That's counting rpn languages where it is 1 1 +. If you don't count them it is 2250. > - How many languages make regular expressions a built-in part of the > language? Almost none of them. There's Perl, obviously, and its > predecessors sed and awk, and probably a few others, but most languages > relegate regular expressions to a library. Yes, like python relegates io to a library. Clearly useful but not indispensable, after all who *really* needs anything beyond print() and input(). And that stuff in math like sin() and exp(). How many programs use that geeky trig stuff? Definitely not indispensable. In fact, now that you pointed it out to me, clearly all that stdlib stuff is dispensable, all one really needs to write "real programmer" programs is just core python. Who the hell needs "sys"! > - How many useful programs can be written with regexes? Clearly there are > many. Some of them would even be quite difficult without regexes. (In > effect, you would have to invent your own pattern-matching code.) Lucky for me then that there are regexes. > - How many useful programs can be written without regexes? Clearly there are > also many. Every time you write a Python program and fail to import re, > you've written one. By golly, you're right. Not every program I write uses regexes. Who would have thought?! However, you failed to establish that the programs I write without re are useful. > Can you call yourself a well-rounded programmer without at least a basic > understanding of some regex library? Well, probably not. But that's part of > the problem with regexes. They have, to some degree, driven out potentially > better -- or at least differently bad -- pattern matching solutions, such > as (E)BNF grammars, SNOBOL pattern matching, or lowly globbing patterns. Or > even alternative idioms, like Hypercard's "chunking" idioms. Hmm, very good point. I wonder why all those "potentially better" solutions have not been more widely adopted? A conspiracy by a secret regex cabal? > When all you have is a hammer, everything looks like a nail. Lucky for us then, that we have more than just hammers! Sorry for the flippant response (well, not really) but I find your arguments pedantic beyond the point of absurdity. For me, regular expressions are indispensable in that if they were not available in Python I would not use Python. The same is true of a number of other stdlib modules. I don't give a rat's ass whether they are in a "library" that has to be explicitly requested with import or a "library" that is automatically loaded at startup. -- https://mail.python.org/mailman/listinfo/python-list
Re: Regular expressions
On Wednesday, November 4, 2015 at 7:31:34 PM UTC-7, Steven D'Aprano wrote: > On Thu, 5 Nov 2015 11:13 am, rurpy wrote: > > > There would be far fewer computer languages, and they would be much > > more primitive if regular expressions (and the fundamental concepts > > that they express) did not exist. > > Well, that's certainly true. But only because contra-factual statements can > imply the truth of anything. If squares had seven sides, then Joseph Stalin > would have been the first woman to go to the moon on horseback. Yes, thank you for that profoundly insightful comment. -- https://mail.python.org/mailman/listinfo/python-list
Re: Regular expressions
On 11/04/2015 05:33 PM, Chris Angelico wrote: > On Thu, Nov 5, 2015 at 11:13 AM, rurpy--- via Python-list > wrote: >> On 11/04/2015 07:52 AM, Chris Angelico wrote: >>> On Thu, Nov 5, 2015 at 1:38 AM, rurpy wrote: I'm afraid you are making a category error but perhaps that's in part because I wasn't clear. I was not talking about computer science. I was talking about human beings learning about computers. Most people I know consider programming to be a higher level activity than "using" a computer: editing, sending email etc. Many computer users (not programmers) learn to use regular expressions as part of using a computer without knowing anything about programming. It was on that basis I called them more fundamental -- something learned earlier which is expanded on and added to later. But you have a bit of a point, perhaps "fundamental" was not the best choice of word to communicate that. >>> >>> The "fundamentals" of something are its most basic functions, not its >>> most basic uses. The most common use of a computer might be to browse >>> the web, but the fundamental functionality is arithmetic and logic. >> >> If one accepted that then one would have to reject the term "fundamental >> use" as meaningless. A quick trip to google shows that's not true. > > A quick trip to Google showed me that there are a number of uses of > the phrase, mostly in scientific papers and such. I've no idea how > that helps your argument. I was showing that your objection to my use of "fundamental" on the grounds it does not apply to "use" is patently silly. From Google: interferes with B's more fundamental use because fundamental use of english The fundamental use of testing Fundamental Use of the Michigan Terminal System negotiate a fundamental use and exchange of power the most fundamental use of pointers makes fundamental use of statistical theory This is what I meant in a recent post when I referred to the Alice- in-Wonderland nature of this group. I'm afraid I don't have the time or interest to discuss basic english with you. If you want to maintain that "fundamental" does apply to "use" please go right ahead, it's your credibility at risk. >> But string matching *is* a fundamental problem that arises frequently >> in many aspects of CS, programming and, as I mentioned, day-to-day >> computer use. Saying its "only" for pattern matching is like saying >> floating point numbers are "only" for doing non-integer arithmetic, >> or unicode is "only" for representing text. (Neither of those is a >> good analogy because both lack the important theoretical underpinnings >> that regular expressions have [*]). > > String matching does happen a lot. How often do you actually need > pattern matching? Most of the time, you're doing equality checks - or > prefix/suffix checks, at best. > >> There would be far fewer computer languages, and they would be much >> more primitive if regular expressions (and the fundamental concepts >> that they express) did not exist. > > So? There would also be far fewer computer languages if braces didn't > exist, because we wouldn't have the interminable arguments about > whether they're good or not. Sorry, that makes no sense to me. >> To be sure, I did gloss over Michael Torries' point that there are >> other concepts that are more basic in the context of learning >> programming, he was correct about that. >> >> But that does not negate the fact that regexes are important and >> fundamental. They are both very useful in a practical sense (they >> are even available in Microsoft Excel) and important in a theoretical >> sense. You are not well rounded as a programmer if you decline to >> learn about regular expressions because "they are too cryptic", or >> "I can do in code anything they do". > > You've proven that they are important, but in no way have you proven > them fundamental. A regular expression library is the ideal solution > to the problem "I want to let my users search for patterns of their > own choosing". That's great, but it's only one specific class of > problem. If you think that is the sole use of pattern matching or even the most important use, I can understand why you find regexes fairly useless. Lexing (tokenization) and simple parsing are often done with regular expressions. Many dozens of times a year I write programs to extract or munge data in text files. Three days ago I had to extract data from a 500MB log file for insertion in a database that used many regexes, even some that could have been replaced by python methods. But mixing the two approaches would have been less clear than using regexs consistently. Text recognition and modification is an *extremely* common need, not some niche application as you suggest. >> I think the constant negative reception the posters receive here when >> they ask about regexes does them a great disservice. >> >> By all means point out
Re: raw_input and break
在 2015年11月4日星期三 UTC-6下午3:45:09，input/ld...@casema.nl写道：
> I have an continues loop with "while True:"
> Now I want to use "raw_input" and when I press "s" on the keybord that it
> will
> "break" the continues loop.
>
> I tried:
> choices = raw_input
> if choises == s:
> break
>
> But even when I not press "s" it "break"
> I want that I not press "s" the script continues.
>
> Any ideas ?
>
> Thanks
>
>
>
> --
> - --- -- -
> Posted with NewsLeecher v7.0 Beta 2
> Web @ http://www.newsleecher.com/?usenet
> --- - -- -
while True:
inp = input("Enter whatever you want, letter 's' to stop: ")
if inp == 's':
print("Program stopped.")
break
print("You just entered:", inp)
Is this along the line that you are thinking? As pointed out earlier, it will
be much easier for people to help if you can share the exact code you put into
and the error messages as well. Thanks and good luck!
All the best,
Tian
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to handle exceptions properly in a pythonic way?
Hi, If I may, I feel you are tying to address a few questions at the same time, although they are related 1. Where to put the try/except block, inside or outside the function 2. How to deal with un-anticipated exceptions 3. How to keep record My personal feelings are: 1. Kind of prefer try/except block outside the function though. This way it looks clean and easy to follow. In terms of logging the url, since you pass it to the function anyway, there should be ways to keep this option, even with the block written outside the function. 2. From code development perspective, would suggest you follow Test Driven Development (TDD) approach. Nobody can anticipate all of the possible outcomes, but I'm sure you have a pretty good idea about the most likely scenarios, and just make sure that your code is suitable for these scenarios. When future new exceptions arise, you can always refactor your code as needed. 3. Feel it's a personal choice here as being pointed out earlier. No mater which way you go, you just have to follow it up and deal with it, trace it back to the root cause. I kind of prefer logging, so to keep a good record for myself, and you can make it very informative. Hope this helps. All the best, Tian -- https://mail.python.org/mailman/listinfo/python-list
Re: How to handle exceptions properly in a pythonic way?
在 2015年11月4日星期三 UTC-6下午10:18:33，zlju...@gmail.com写道： > > Which would you prefer? > > So if I am just checking for the ConnectionError in get_html and a new > exception arises, I will have traceback to the get_html function showing that > unhandled exception has happened. > Now I have to put additional exception block for managing the new exception > in the get_html function and I am covered. > > Is that what you wanted to say? Hi, If I may, I feel you are trying to address a few separate questions, although they do relate to each other. 1. Coding Design: with the try/except block inside or outside the function 2. Exception Handling: What to do with new un-anticipated exceptions 3. How to record the exception for reference: logging or special value My feeling is: 1. Personally prefer to put try/except block outside the function, to keep the code clean and easy to follow. 2. I would suggest follow the Test Driven Development (TDD) approach. You are not able to anticipate all types of possible exceptions. However, I'm sure you have a pretty good idea about what exceptions are more likely to happen and cause you problem. In that case, just develop your code to pass these tests, and refactor it in the future if really needed. Not necessary to push your code to be perfect, able to handle every possible exception. 3. Kind of personal choice here, since no matter which way you go, you do need to follow it up and deal with them. Probably I would log it just for record keeping purpose. As long as you follow up and trace back to the root cause, they seem to serve the same goal. Hope this helps... All the best, Tian -- https://mail.python.org/mailman/listinfo/python-list
Re: How to handle exceptions properly in a pythonic way?
On Thu, Nov 5, 2015 at 3:18 PM, wrote: >> Which would you prefer? > > So if I am just checking for the ConnectionError in get_html and a new > exception arises, I will have traceback to the get_html function showing that > unhandled exception has happened. > Now I have to put additional exception block for managing the new exception > in the get_html function and I am covered. > > Is that what you wanted to say? Yep. I would definitely recommend having get_html raise an exception on any problem; here's the structure I'd use: def get_html(...): try: ... actually go get the info return info except (ConnectionError, OSError, SocketError) as e: raise ContentNotFoundError from e This means there are three possibilities: 1) Everything works correctly, and get_html returns something useful. 2) An exception occurs of a type that you expect - the server didn't respond, or the OS threw back a failure, or whatever. (You'd decide what set of exceptions this represents.) In this case, you get a single exception that wraps that up and summarizes the problem as "Content Not Found". The original exception is retained in the __cause__ of the ContentNotFoundError, so no information is lost. 3) An unexpected exception occurs - your script runs out of memory, or there's a bug in your code, or anything else. The exception will simply bubble up, and be dealt with somewhere else. To use this code, what you'd do is: try: data = get_html(...) except ContentNotFoundError: # deal with the case of not having anything to work with Omitting the try/except is a perfectly reasonable way of working, too. Just call get_html, and if ever it can't get a result, the exception continues to propagate. It's easy, it's straight-forward, and it's unambiguous - any problem you don't expect becomes an exception. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: How to handle exceptions properly in a pythonic way?
> Which would you prefer? So if I am just checking for the ConnectionError in get_html and a new exception arises, I will have traceback to the get_html function showing that unhandled exception has happened. Now I have to put additional exception block for managing the new exception in the get_html function and I am covered. Is that what you wanted to say? -- https://mail.python.org/mailman/listinfo/python-list
Re: How to handle exceptions properly in a pythonic way?
On Monday, 2 November 2015 21:59:45 UTC+1, Ian wrote:
> I'm having a hard time understanding what question you're asking.
:)
I am really having a hard time to explain the problem as English is not my
first language.
> You
> have a lot of discussion about where to handle exceptions,
That's right. I am not sure where to handle exceptions and at the same time to
have the code clean as possible.
For example John from the previous post suggested raising exceptions in the
get_html procedure. That would mean that I should put every call of get_html
function to the try/except block.
In this particular example, I would like just to know whether I managed to
get_html or not.
In case I am experiencing some problems inside of the get_html function I could
maybe retry several times, but this function should return the html or inform
the caller that it is unable to get the html. For caller, the reason why
get_html function couldn't get the html is not important.
For now, I am thinking that maybe I should use an approach in which I will have
except block in get_html that will be responsible for several exceptions,
something like this:
def get_html(url):
try:
wpage = requests.get(url)
except ConnectionError, exception_a, exceptionb...:
flog('warning', 'ConnectionError exception', log_except=True)
raise NoHtml
return
In that way the caller can put get_html function in try/except block but just
paying an attention to the NoHtml exception which is much clearer than to have
except ConnectionError
except exception_a
except exceptionb...:
in every call of the get_html.
> but the
> examples that you show are of logging the the exception and re-raising
> it, which is a good practice but distinct from handling the exception.
I mentioned logging in get_html because I don't know what else I should do with
an exception in get_html function.
> Then you seem to be asking about the practice of returning None as an
> alternative to propagating the exception, but the example you show
> only returns None in a case where no exception was raised in the first
> place.
I returned None based of the wpage.status_code == requests.codes.ok.
I assume that if this condition is true, everything went well.
Otherwise, I could forget to put some explicit exceptions in the except block
so try block will pass even if certain exception has happened.
I read that catching all exception with except Exception as e: is not a good
option.
> None is arguably reasonable to return when it makes sense as a
> non-exceptional value in the context. For example, if you're looking
> up a policy that may or may not exist, then your get_policy function
> might return None to indicate no value. If get_policy fails because of
> an RPC timeout however, then it needs to raise an exception rather
> than possibly incorrectly returning "no policy".
If I understood correctly, in my case I could ask for getting the html from non
existent web page or I can have communication (network) problem.
In any of these two cases if I return None I will newer know that web page
doesn't exist. Good point.
> In comparison, if you're returning something that should always have a
> value, then you should never return None. In such a case, None would
> indicate that something went wrong, but it lacks any information about
> *what* went wrong. An exception, on the other hand, is ideal for
> carrying that sort of information. Returning None in such a scenario
> is also risky in that the caller may not be expecting None and may try
> to treat it as a normal value. In some cases this may even appear to
> work until something breaks in a completely different part of the
> code.
So my get_html function should never return None in that case.
> In the example given, the case where None is returned is clearly an
> exceptional case (non-success) even though no exception was raised by
> requests.get. You should raise an exception there instead of returning
> None to allow the caller better control over the situation.
I am kind of getting the philosophy of exceptions but I still have some
dilemmas as you could see above.
Thank you very much for your comments.
Regards.
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to handle exceptions properly in a pythonic way?
On Thu, Nov 5, 2015 at 2:41 PM, wrote: > Raising an exception forces me to put every call of the get_html function in > try/except block. > If I am returning a special value, than I can call get_html and then test the > value. > > I am not sure which approach is better. Raising an exception means that if you fail to put it in a try/except, you get a traceback that walks you through the exact location of the problem. Returning a special value means that if you fail to test the value, you either get an exception further on (if you get back None and try to treat it as a string, for instance), or get incorrect results, with no indication of the actual cause of the problem. Which would you prefer? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: How to handle exceptions properly in a pythonic way?
> The best way is probably to do nothing at all, and let the caller handle > any exceptions. In that case every call of the get_html function has to be in the try/except block with many exceptions. Sometimes, it is enough just to know whether I managed to get the html or not. In that case, I could for example, in get_html have try/except block which will as result raise let's say NoHtml custom exception or return some special value. Raising an exception forces me to put every call of the get_html function in try/except block. If I am returning a special value, than I can call get_html and then test the value. I am not sure which approach is better. -- https://mail.python.org/mailman/listinfo/python-list
Re: Regular expressions
Steven D'Aprano writes: > Yes yes, I know that regexes aren't the only tool in my tool box, but > *right now* I want to learn how to use regexes. I'll gently suggest this isn't a particularly good forum to do so. Learn them with a tool like http://www.regexr.com/> and a tutorial http://www.usna.edu/Users/cs/wcbrown/regexp/RegexpTutorial.html> or something longer. -- \“Fascism is capitalism plus murder.” —Upton Sinclair | `\ | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Regular expressions
Steven D'Aprano writes:
> On Wed, 4 Nov 2015 07:57 pm, Peter Otten wrote:
>
> > I tried Tim's example
> >
> > $ seq 5 | grep '1*'
> > 1
> > 2
> > 3
> > 4
> > 5
> > $
>
> I don't understand this. What on earth is grep matching? How does "4"
> match "1*"?
You can experiment with regular expressions to find out. Here's a link
to the RegExr tool for the above pattern http://regexr.com/3c4ot>.
Matching patterns can include specifications meaning “match some number
of the preceding segment”, with the ‘{n,m}’ notation. That means “match
at least n, and at most m, occurrences of the preceding segment”. Either
‘n’ or ‘m’ can be omitted, meaning “at least 0” and “no maximum”
respectively.
Those are quite useful, so there are shortcuts for the most common
cases: ‘?’ is a short cut for ‘{0,1}’, ‘*’ is a short cut for ‘{0,}’,
and ‘+’ is a short cut for ‘{1,}’.
In this case, ‘*’ is a short cut for ‘{0,}’ meaning “match 0 or more
occurences of the preceding segment”. The segment here is the atom ‘1’.
Since ‘1*’ is the entirety of the pattern, the pattern can match zero
characters, anywhere within any string. So, it matches every possible
string.
To match (some atom) 1 or more times, ‘+’ is a short cut for ‘(1,}’
meaning “match 1 or more occurrences of the preceding segment”.
--
\學而不思則罔，思而不學則殆。 (To study and not think is a waste. |
`\ To think and not study is dangerous.) |
_o__)—孔夫子 Confucius (551 BCE – 479 BCE) |
Ben Finney
--
https://mail.python.org/mailman/listinfo/python-list
Re: Regular expressions
On 2015-11-05 13:28, Steven D'Aprano wrote: > > I tried Tim's example > > > > $ seq 5 | grep '1*' > > 1 > > 2 > > 3 > > 4 > > 5 > > $ > > I don't understand this. What on earth is grep matching? How does > "4" match "1*"? The line with "4" matches "zero or more 1s". If it was searching for a literal "1*" (as would happen with fgrep or "grep -F"), it would return no results: $ seq 5 | fgrep '1*' $ -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Regular expressions
On Thu, Nov 5, 2015 at 11:24 AM, rurpy--- via Python-list wrote: > On Wednesday, November 4, 2015 at 4:05:06 PM UTC-7, Seymore4Head wrote: >>[...] >> I am still here, but I have to admit I am not picking up too much. > > The "take away" I recommend is: the folks here are often way > overly negative regarding regular expressions and that you not > ignore them, but take them with a BIG grain of salt and continue > learning about and using regexs. > > You will find they are an indispensable tool, not just in Python > programming but in many aspects of computer use. The "take away" that I recommend is: Rurpy loves to argue in favour of regular expressions, but as you can see from the other posts, there are alternatives, which are often FAR superior. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Regular expressions
On Thu, 5 Nov 2015 11:13 am, ru...@yahoo.com wrote:
> There would be far fewer computer languages, and they would be much
> more primitive if regular expressions (and the fundamental concepts
> that they express) did not exist.
Well, that's certainly true. But only because contra-factual statements can
imply the truth of anything. If squares had seven sides, then Joseph Stalin
would have been the first woman to go to the moon on horseback.
I can't imagine a world where pattern matching doesn't exist. That's like
trying to imagine a world where arithmetic doesn't exist. But I think we
can safely say that, had nobody thought of the idea of searching for
patterns ('find me all the lines with "green" in them'), there would be far
fewer regex libraries in existence. I doubt that there would be "far fewer"
programming languages. With the possible exception of Perl, sed and awk,
I'm not aware of any languages which were specifically inspired by, and
exist primarily to apply, regular expressions, nor any languages which
*require* regexes in their implementation. Most languages are built on
parsers, not regular expressions.
> But I really wish every mention of regexes here wasn't reflexively
> greeted with a barrage of negative comments and that lame "two problems"
> quote, especially without an answer to the poster's regex question.
I don't disagree with this. Certainly we should accept questions from people
who are simply trying to learn how to use regexes without bombarding them
with admonitions to do something different. Yes yes, I know that regexes
aren't the only tool in my tool box, but *right now* I want to learn how to
use regexes.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: Regular expressions
On Wed, 4 Nov 2015 07:57 pm, Peter Otten wrote:
> I tried Tim's example
>
> $ seq 5 | grep '1*'
> 1
> 2
> 3
> 4
> 5
> $
I don't understand this. What on earth is grep matching? How does "4"
match "1*"?
> which surprised me because I remembered that there usually weren't any
> matching lines when I invoked grep instead of egrep by mistake. So I tried
> another one
>
> $ seq 5 | grep '[1-3]+'
> $
>
> and then headed for the man page. Apparently there is a subset called
> "basic regular expressions":
>
> """
> Basic vs Extended Regular Expressions
>In basic regular expressions the meta-characters ?, +, {, |, (,
>and ) lose their special meaning; instead use the backslashed
>versions \?, \+, \{, \|, \(, and \).
> """
None of this appears relevant, as the metacharacter * is not listed. So
what's going on?
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: Regular expressions
On Thu, 5 Nov 2015 11:24 am, ru...@yahoo.com wrote: > You will find they are an indispensable tool, not just in Python > programming but in many aspects of computer use. You will find them a useful tool, but not indispensable by any means. Hint: - How many languages make arithmetic a built-in part of the language? Almost all of them. I don't know of any language that doesn't let you express something like "1 + 1" using built-in functions or syntax. Arithmetic is much closer to indispensable. - How many languages make regular expressions a built-in part of the language? Almost none of them. There's Perl, obviously, and its predecessors sed and awk, and probably a few others, but most languages relegate regular expressions to a library. - How many useful programs can be written with regexes? Clearly there are many. Some of them would even be quite difficult without regexes. (In effect, you would have to invent your own pattern-matching code.) - How many useful programs can be written without regexes? Clearly there are also many. Every time you write a Python program and fail to import re, you've written one. Can you call yourself a well-rounded programmer without at least a basic understanding of some regex library? Well, probably not. But that's part of the problem with regexes. They have, to some degree, driven out potentially better -- or at least differently bad -- pattern matching solutions, such as (E)BNF grammars, SNOBOL pattern matching, or lowly globbing patterns. Or even alternative idioms, like Hypercard's "chunking" idioms. When all you have is a hammer, everything looks like a nail. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Regular expressions
On Thu, 5 Nov 2015 10:02 am, Seymore4Head wrote: > So far the only use I have for regex is to replace slicing, but I > think it is an improvement. I don't understand this. This is like saying "so far the only use I have for a sandwich press is to replace my coffee pot". Regular expressions and slicing do very different things. Slicing extracts substrings, given known starting and ending positions: py> the_str = "Now is the time for all good men..." py> the_str[7:12] 'the t' Regular expressions don't extract substrings with known start/end positions. They *find* matching text, giving a search string with metacharacters. (If there are no metacharacters in your search string, you shouldn't use a regex. str.find will be significantly faster and more convenient.) Slicing is not about finding text, it is about extracting text once you've already found it. So they are complementary, not alternatives. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: raw_input and break
On Thu, 5 Nov 2015 09:37 am, input/ldompel...@casema.nl wrote: > I quote the s, but its still break even when I not press the s. The code you have shown us is so full of bugs and typos that you cannot possibly be running that code. Unfortunately, we do not have magical powers. We cannot see the code you *actually* run, only the code you show us. So if you want help, you need to show us the code you actually run. COPY AND PASTE -- do not retype from memory -- the while loop from your code. Make sure it will run on its own. If you can't run the code, because it lacks variables or something else, neither can we. Help us to help you. We cannot help you unless you show us the code you are running. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: What does “grep” stand for?
On Thu, Nov 5, 2015 at 6:38 AM, Christian Gollwitzer wrote: > Am 04.11.15 um 19:24 schrieb Ben Finney: >> >> The name is a mnemonic for a compound command in ‘ed’ [0], a text editor >> that pre-dates extravagant luxuries like “presenting a full screen of >> text at one time”. >> >> [... lots of fun facts ...] > > > Here is another fun fact: The convincing UI of ed was actually so widely > applied, that even Microsoft included a similar editor into MSDOS, called > EDLIN. EDLIN, of course, was a bastardized version of ed that could do much > less and also lacked regular expressions. Needless to say that the mighty > "VIsual" editor was out 5 years before MSDOS shipped EDLIN as the only > editor... > > In contrast to ed, the stream editor "sed" is used multiple times avery day > in a typical Unix session inside shell scripts to perform automated text > processing tasks, including regex replacement. As someone who grew up on MS-DOS, I'd like to mention that EDLIN's value wasn't in the obvious places. There were two features it had that most other editors didn't: firstly, it would read only as much of the file as it needed, so you could edit a file larger than available memory; and secondly, all commands came from stdin, which could be redirected - making it a poor man's 'sed'. Using EDLIN for regular file editing was never the normal thing. Fast forward a decade or two, and I'm working on a MUD server for a friend. It incorporates an editor that can be used on a dumb telnet connection - and it's line based again. So there's clearly some value here :) Visual editors get the lion's share of actual editing work, but in special circumstances, it is nice to have a quick little ed-like program around. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Regular expressions
On Thu, Nov 5, 2015 at 11:13 AM, rurpy--- via Python-list wrote: > On 11/04/2015 07:52 AM, Chris Angelico wrote: >> On Thu, Nov 5, 2015 at 1:38 AM, rurpy wrote: >>> I'm afraid you are making a category error but perhaps that's in >>> part because I wasn't clear. I was not talking about computer >>> science. I was talking about human beings learning about computers. >>> Most people I know consider programming to be a higher level activity >>> than "using" a computer: editing, sending email etc. Many computer >>> users (not programmers) learn to use regular expressions as part >>> of using a computer without knowing anything about programming. >>> It was on that basis I called them more fundamental -- something >>> learned earlier which is expanded on and added to later. But you >>> have a bit of a point, perhaps "fundamental" was not the best choice >>> of word to communicate that. >> >> The "fundamentals" of something are its most basic functions, not its >> most basic uses. The most common use of a computer might be to browse >> the web, but the fundamental functionality is arithmetic and logic. > > If one accepted that then one would have to reject the term "fundamental > use" as meaningless. A quick trip to google shows that's not true. A quick trip to Google showed me that there are a number of uses of the phrase, mostly in scientific papers and such. I've no idea how that helps your argument. > But string matching *is* a fundamental problem that arises frequently > in many aspects of CS, programming and, as I mentioned, day-to-day > computer use. Saying its "only" for pattern matching is like saying > floating point numbers are "only" for doing non-integer arithmetic, > or unicode is "only" for representing text. (Neither of those is a > good analogy because both lack the important theoretical underpinnings > that regular expressions have [*]). String matching does happen a lot. How often do you actually need pattern matching? Most of the time, you're doing equality checks - or prefix/suffix checks, at best. > There would be far fewer computer languages, and they would be much > more primitive if regular expressions (and the fundamental concepts > that they express) did not exist. So? There would also be far fewer computer languages if braces didn't exist, because we wouldn't have the interminable arguments about whether they're good or not. > To be sure, I did gloss over Michael Torries' point that there are > other concepts that are more basic in the context of learning > programming, he was correct about that. > > But that does not negate the fact that regexes are important and > fundamental. They are both very useful in a practical sense (they > are even available in Microsoft Excel) and important in a theoretical > sense. You are not well rounded as a programmer if you decline to > learn about regular expressions because "they are too cryptic", or > "I can do in code anything they do". You've proven that they are important, but in no way have you proven them fundamental. A regular expression library is the ideal solution to the problem "I want to let my users search for patterns of their own choosing". That's great, but it's only one specific class of problem. > I think the constant negative reception the posters receive here when > they ask about regexes does them a great disservice. > > By all means point out that python offers a number of functions that > can avoid the need for using regexes in simple cases. Even point out > that you (the plural you) don't like them and prefer other solutions > (like writing code that does the same thing in a more half-assed bug > ridden way, the posts in this thread being a case in point.) > > But I really wish every mention of regexes here wasn't reflexively > greeted with a barrage of negative comments and that lame "two problems" > quote, especially without an answer to the poster's regex question. When has that happened? Usually there'll be at least two answers - one that uses a regex and one that doesn't - and people get to read both. >> Sure, you can >> abuse that into a primality check and other forms of crazy arithmetic, >> but it's not what they truly do. I also would not teach regexes to >> people as part of an "introduction to computing" course, any more than >> I would teach the use of Microsoft Excel, which some such courses have >> been known to do. (And no, it's not because of the Microsoftness. I >> wouldn't teach LibreOffice Calc either.) You don't need to know how to >> work a spreadsheet as part of the basics of computer usage, and you >> definitely don't need an advanced form of text search. > > Seems to me that clearly depends on the intent of the class, the students > goal's, what they'll be studying after the class, what their current > level of knowledge is, etc. Your scenario seems way too under-specified > to say anything definitive. And further, the pedagogy of CS (or of any > subject of education) is not "set
Re: Regular expressions
On Wednesday, November 4, 2015 at 4:05:06 PM UTC-7, Seymore4Head wrote: >[...] > I am still here, but I have to admit I am not picking up too much. The "take away" I recommend is: the folks here are often way overly negative regarding regular expressions and that you not ignore them, but take them with a BIG grain of salt and continue learning about and using regexs. You will find they are an indispensable tool, not just in Python programming but in many aspects of computer use. -- https://mail.python.org/mailman/listinfo/python-list
Re: Regular expressions
On 11/04/2015 07:52 AM, Chris Angelico wrote: > On Thu, Nov 5, 2015 at 1:38 AM, rurpy wrote: >> I'm afraid you are making a category error but perhaps that's in >> part because I wasn't clear. I was not talking about computer >> science. I was talking about human beings learning about computers. >> Most people I know consider programming to be a higher level activity >> than "using" a computer: editing, sending email etc. Many computer >> users (not programmers) learn to use regular expressions as part >> of using a computer without knowing anything about programming. >> It was on that basis I called them more fundamental -- something >> learned earlier which is expanded on and added to later. But you >> have a bit of a point, perhaps "fundamental" was not the best choice >> of word to communicate that. > > The "fundamentals" of something are its most basic functions, not its > most basic uses. The most common use of a computer might be to browse > the web, but the fundamental functionality is arithmetic and logic. If one accepted that then one would have to reject the term "fundamental use" as meaningless. A quick trip to google shows that's not true. > Setting aside the choice of word, though, I still don't think regular > expressions are a more basic use of computing than loops and > conditionals. A regex can't be used for anything other than string > matching; they exist for one purpose, and one purpose only: to answer > the question "Does this string match this pattern?". But string matching *is* a fundamental problem that arises frequently in many aspects of CS, programming and, as I mentioned, day-to-day computer use. Saying its "only" for pattern matching is like saying floating point numbers are "only" for doing non-integer arithmetic, or unicode is "only" for representing text. (Neither of those is a good analogy because both lack the important theoretical underpinnings that regular expressions have [*]). There would be far fewer computer languages, and they would be much more primitive if regular expressions (and the fundamental concepts that they express) did not exist. To be sure, I did gloss over Michael Torries' point that there are other concepts that are more basic in the context of learning programming, he was correct about that. But that does not negate the fact that regexes are important and fundamental. They are both very useful in a practical sense (they are even available in Microsoft Excel) and important in a theoretical sense. You are not well rounded as a programmer if you decline to learn about regular expressions because "they are too cryptic", or "I can do in code anything they do". I think the constant negative reception the posters receive here when they ask about regexes does them a great disservice. By all means point out that python offers a number of functions that can avoid the need for using regexes in simple cases. Even point out that you (the plural you) don't like them and prefer other solutions (like writing code that does the same thing in a more half-assed bug ridden way, the posts in this thread being a case in point.) But I really wish every mention of regexes here wasn't reflexively greeted with a barrage of negative comments and that lame "two problems" quote, especially without an answer to the poster's regex question. > Sure, you can > abuse that into a primality check and other forms of crazy arithmetic, > but it's not what they truly do. I also would not teach regexes to > people as part of an "introduction to computing" course, any more than > I would teach the use of Microsoft Excel, which some such courses have > been known to do. (And no, it's not because of the Microsoftness. I > wouldn't teach LibreOffice Calc either.) You don't need to know how to > work a spreadsheet as part of the basics of computer usage, and you > definitely don't need an advanced form of text search. Seems to me that clearly depends on the intent of the class, the students goal's, what they'll be studying after the class, what their current level of knowledge is, etc. Your scenario seems way too under-specified to say anything definitive. And further, the pedagogy of CS (or of any subject of education) is not "settled science" and that kind of question almost never has a clear right/wrong answer. This list is not a class. If someone comes here with a question about Python's regexes they deserve an answer and not be bombarded with reasons why they shouldn't be using regexes beyond mentioning some of the alternatives in a "oh, by the way" way. (And yes, I recognize in this case the OP did get a good answer from MRAB early on.) [*] yes, I know there is a lot of CS theory underlying floating point. I don't think it is as deep or as important as that underlying regexes, automata and language. -- https://mail.python.org/mailman/listinfo/python-list
OT ish History Channel - The Invention of the Internet
https://www.youtube.com/watch?v=M9ebkjWU6Z4 -- https://mail.python.org/mailman/listinfo/python-list
Re: Regular expressions
On Wed, 4 Nov 2015 18:08:51 -0500, Terry Reedy wrote: >On 11/3/2015 10:23 PM, Steven D'Aprano wrote: > >> I don't even know what grep stands for. > >Get Regular Expression & Print Thanks, I may get around to that eventually. -- https://mail.python.org/mailman/listinfo/python-list
Re: any practise site about python?
On Wed, Nov 4, 2015 at 5:59 PM, Emile van Sebille wrote: > On 11/4/2015 11:38 AM, alperen wrote: > >> hi guys. >> i am computer engineering student and i want to practise the lectures >> that i saw at school. for example dictionaries tuples or some other topics. >> i know eulerproject but it is hard for starting. do you know any exercise >> sites for students or beginners >> >> > Any of the top four hits googling 'getting started with python' should > provide you a thread to pull on. > > Emile > > > -- > https://mail.python.org/mailman/listinfo/python-list > The python tutorial at python.org is good. Also, python the hard way is good. -- Joel Goldstick http://joelgoldstick.com/stats/birthdays -- https://mail.python.org/mailman/listinfo/python-list
Re: Regular expressions
On Wed, 04 Nov 2015 14:48:21 +1100, Steven D'Aprano wrote: >On Wednesday 04 November 2015 11:33, ru...@yahoo.com wrote: > >>> Not quite. Core language concepts like ifs, loops, functions, >>> variables, slicing, etc are the socket wrenches of the programmer's >>> toolbox. Regexs are like an electric impact socket wrench. You can do >>> the same work without it, but in many cases it's slower. But you have to >>> learn the other hand tools first in order to really use the electric >>> driver properly (understanding torques, direction of threads, etc), lest >>> you wonder why you're breaking off so many bolts with the torque of the >>> impact drive. >> >> I consider regexs more fundemental > >I'm sure that there are people who consider the International Space Station >more fundamental than the lever, the wedge and the hammer, but they would be >wrong too. > >Given primitives for branching, loops and variables, you can build support >for regexes. Given regexes, how would you build support for variables? > >Of course, you could easily prove me wrong. All you would need to do to >demonstrate that regexes are more fundamental than branching, loops and >variables would be to demonstrate that the primitive operations available in >commonly used CPUs are regular expressions, and that (for example) C's for >loop and if...else are implemented in machine code as regular expressions, >rather than the other way around. So far the only use I have for regex is to replace slicing, but I think it is an improvement. -- https://mail.python.org/mailman/listinfo/python-list
Re: Bugfixing python 3.5 asyncio
Hello, Yes, the fix has been merged. If 3.5.1 gets released in a month, it should not be a problem. And looks like it dpends on http://bugs.python.org/issue25446 . Thank you for the information. Dmitry On Wed, Nov 4, 2015 at 5:52 PM, Terry Reedy wrote: > On 11/3/2015 8:24 PM, Dmitry Panteleev wrote: >> >> Hello, >> >> There is a bug in asyncio.Queue >> (https://github.com/python/asyncio/issues/268), which makes it >> unusable for us. It is fixed in master now. > > > I presume that the fix has been merged into the CPython repository (you > could check). If so, it should be included when 3.5.1 is released in about > a month+. > >> What is the easiest way to >> patch the asyncio bundled with python if I have to distribute it among >> 5 colleagues? It is used in our private module. > > > The cleanest way -- in my opinion -- would be to patch your 3.5.0 > installations, making them '3.5.0+'. For 5 installations, > >> I can think of: >> 1. Copy asyncio.queues into our package so it has a different name > > > this would be easiest, but then I would retest and presumably revise and > redistribute after 3.5.1 is out > >> 2. Override sys.path >> >> Both look really strange. Is there anything else? > > > What I said above. > > -- > Terry Jan Reedy > > -- > https://mail.python.org/mailman/listinfo/python-list -- Best Regards, Dmitry Panteleev -- https://mail.python.org/mailman/listinfo/python-list
Re: Regular expressions
On 11/3/2015 10:23 PM, Steven D'Aprano wrote: I don't even know what grep stands for. Get Regular Expression & Print -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Regular expressions
On Wed, 04 Nov 2015 08:13:51 -0700, Michael Torrie
wrote:
>On 11/04/2015 01:57 AM, Peter Otten wrote:
>> and then headed for the man page. Apparently there is a subset
>> called "basic regular expressions":
>>
>> """> Basic vs Extended Regular Expressions
>>In basic regular expressions the meta-characters ?, +, {, |, (,
>>and ) lose their special meaning; instead use the backslashed
>>versions \?, \+, \{, \|, \(, and \).
>> """
>
>Good catch. I think this must have been what my brain was thinking when
>I commented about grep and regular expressions earlier. I checked the
>man page but didn't read down far enough.
>
>I was still technically wrong though.
>
>It's neat to learn so much on these tangents that the python list goes
>on frequently. Hope the OP is still lurking, reading all these comments,
>though I suspect he's not.
>
I am still here, but I have to admit I am not picking up too much.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Unbuffered stderr in Python 3
On 11/3/2015 10:18 PM, Steven D'Aprano wrote:
On Wednesday 04 November 2015 09:25, Terry Reedy wrote:
On 11/3/2015 10:42 AM, Chris Angelico wrote:
On Wed, Nov 4, 2015 at 2:00 AM, Random832 wrote:
Nobody writes:
It's probably related to the fact that std{in,out,err} are Unicode
streams.
There's no fundamental reason a Unicode stream should have to be line
buffered. If it's "related", it's only in that an oversight was made in
the course of making that change.
The current behavior is not an 'oversight'. I was considered, decided,
and revisited in https://bugs.python.org/issue13601. Guido:
"Line-buffering should be good enough since in practice errors messages
are always terminated by a newline." If not, print(part_line,
file=sys.stderr, flush=True) works for the unusual case.
This is one of the offending line from our code base:
print('<4>Suspicious answer "{}"!'.format(answer), file=sys.stderr)
So that ought to be terminated by a newline.
Or include 'flush=True' if you really want that to be a partial line.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: any practise site about python?
On 11/4/2015 11:38 AM, alperen wrote: hi guys. i am computer engineering student and i want to practise the lectures that i saw at school. for example dictionaries tuples or some other topics. i know eulerproject but it is hard for starting. do you know any exercise sites for students or beginners Any of the top four hits googling 'getting started with python' should provide you a thread to pull on. Emile -- https://mail.python.org/mailman/listinfo/python-list
Re: Bugfixing python 3.5 asyncio
On 11/3/2015 8:24 PM, Dmitry Panteleev wrote: Hello, There is a bug in asyncio.Queue (https://github.com/python/asyncio/issues/268), which makes it unusable for us. It is fixed in master now. I presume that the fix has been merged into the CPython repository (you could check). If so, it should be included when 3.5.1 is released in about a month+. What is the easiest way to patch the asyncio bundled with python if I have to distribute it among 5 colleagues? It is used in our private module. The cleanest way -- in my opinion -- would be to patch your 3.5.0 installations, making them '3.5.0+'. For 5 installations, I can think of: 1. Copy asyncio.queues into our package so it has a different name this would be easiest, but then I would retest and presumably revise and redistribute after 3.5.1 is out 2. Override sys.path Both look really strange. Is there anything else? What I said above. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: raw_input and break
In reply to "Joel Goldstick" who wrote the following: > On Wed, Nov 4, 2015 at 4:44 PM, wrote: > > > I have an continues loop with "while True:" > > Now I want to use "raw_input" and when I press "s" on the keybord that it > > will > > "break" the continues loop. > > > > I tried: > > choices = raw_input > > if choises == s: > > break > > You need to quote the s: > if choices == 's' I quote the s, but its still break even when I not press the s. -- >But even when I not press "s" it "break" > > I want that I not press "s" the script continues. > > > > Any ideas ? > > > > You need to quote the s: > if choices == 's' > > you need to check your spelling -- you have choices and choises > > You need to indent break 4 spaces > > > > > Thanks > > > > > > > > -- > > - --- -- - > > Posted with NewsLeecher v7.0 Beta 2 > > Web @ http://www.newsleecher.com/?usenet > > --- - -- - > > > > -- > > https://mail.python.org/mailman/listinfo/python-list > > > > > > -- > Joel Goldstick > http://joelgoldstick.com/stats/birthdays -- - --- -- - Posted with NewsLeecher v7.0 Beta 2 Web @ http://www.newsleecher.com/?usenet --- - -- - -- https://mail.python.org/mailman/listinfo/python-list
Re: raw_input and break
On Wed, Nov 4, 2015 at 4:44 PM, wrote: > I have an continues loop with "while True:" > Now I want to use "raw_input" and when I press "s" on the keybord that it > will > "break" the continues loop. > > I tried: > choices = raw_input > if choises == s: > break > > But even when I not press "s" it "break" > I want that I not press "s" the script continues. > > Any ideas ? > You need to quote the s: if choices == 's' you need to check your spelling -- you have choices and choises You need to indent break 4 spaces > > Thanks > > > > -- > - --- -- - > Posted with NewsLeecher v7.0 Beta 2 > Web @ http://www.newsleecher.com/?usenet > --- - -- - > > -- > https://mail.python.org/mailman/listinfo/python-list > -- Joel Goldstick http://joelgoldstick.com/stats/birthdays -- https://mail.python.org/mailman/listinfo/python-list
Re: raw_input and break
On Wed, Nov 4, 2015 at 2:44 PM, wrote: > I have an continues loop with "while True:" > Now I want to use "raw_input" and when I press "s" on the keybord that it will > "break" the continues loop. > > I tried: > choices = raw_input This doesn't call raw_input. For that you need to write raw_input(), where the parentheses indicate a function call. All the above does is find the raw_input function and assign that function to the name "choices". > if choises == s: Strings in Python are delimited with quotes: "s", not just s. The latter is going to try to look up a variable named s, not denote a string. Also, it's important to spell the variable here in the same way that you did above. Above you have a c where here there is an s. I'm assuming that this isn't exactly what you ran, because you most likely would have gotten a NameError here. Please copy and paste exactly the code that you're trying to run rather than retyping it. > break This needs to be indented. Not indenting it would be a SyntaxError, so again I'm guessing that this isn't actually what you ran. -- https://mail.python.org/mailman/listinfo/python-list
raw_input and break
I have an continues loop with "while True:" Now I want to use "raw_input" and when I press "s" on the keybord that it will "break" the continues loop. I tried: choices = raw_input if choises == s: break But even when I not press "s" it "break" I want that I not press "s" the script continues. Any ideas ? Thanks -- - --- -- - Posted with NewsLeecher v7.0 Beta 2 Web @ http://www.newsleecher.com/?usenet --- - -- - -- https://mail.python.org/mailman/listinfo/python-list
Re: teacher need help!
On Wed, Nov 4, 2015 at 11:18 AM, Storey, Geneva
wrote:
>
>
>
>
> I am having the same problem that we experienced earlier (see below). This
> student was exploring random numbers in Python. She named her program random
> which caused confusion for her computer. We deleted the file, but still had
> the problem.
Was there a lingering .pyc file? The following transcript is from
Linux but still illustrative of the probable cause.
$ echo 'print("Oops!")' > random.py
$ ls random.*
random.py
$ python -c "import random"
Oops!
$ ls random.*
random.py random.pyc
$ rm random.py
$ python -c "import random"
Oops!
$ rm random.pyc
$ python -c "import random"
> I removed Python from the machine. When I tried to reinstall, I got the
> attached error message. Now it won't even install. Any suggestions would be
> greatly appreciated!
Unfortunately the attachment doesn't seem to have made it through.
Also, many of the subscribers here read this mailing list as a Usenet
group and wouldn't be able to see the attachment anyway. Please copy
and paste the error instead.
--
https://mail.python.org/mailman/listinfo/python-list
Re: CherryPy cpstats and ws4py
Ok, let me ask a different question: the impression I have gotten when trying
to find help with CherryPy in general and ws4py specifically is that these
frameworks are not widely used or well supported. Is that a fair assessment, or
do I just have issues that are outside the realm of experience for other users?
If it is a fair assessment, should I be looking at a different product for my
next project? I know there are a number of options, CherryPy was simply the
first one suggested to me, and ws4py is what is listed in their docs as the
framework to use for Web Sockets.
Thanks for any feedback that can be provided.
---
Israel Brewster
Systems Analyst II
Ravn Alaska
5245 Airport Industrial Rd
Fairbanks, AK 99709
(907) 450-7293
---
> On Nov 3, 2015, at 8:05 AM, Israel Brewster wrote:
>
> I posted this to the CherryPy and ws4py mailing lists, but in the week since
> I did that I've only gotten two or three views on each list, and no
> responses, so as a last-ditch effort I thought I'd post here. Maybe someone
> with more general python knowledge than me can figure out the traceback and
> from there a solution.
>
> Is it possible to use ws4py in conjunction with the cpstats CherryPy tool? I
> have a CherryPy (3.8.0) web app that uses web sockets via ws4py. Tested and
> working. I am now trying to get a little more visibility into the functioning
> of the server, so to that end I enabled the cpstats tool by adding the
> following line to my '/' configuration:
>
> tools.cpstats.on=True
>
> Unfortunately, as soon as I do that, attempts to connect a web socket start
> failing with the following traceback:
>
> [28/Oct/2015:08:18:48]
> Traceback (most recent call last):
> File
> "/Library/Python/2.7/site-packages/CherryPy-3.8.0-py2.7.egg/cherrypy/_cprequest.py",
> line 104, in run
>hook()
> File
> "/Library/Python/2.7/site-packages/CherryPy-3.8.0-py2.7.egg/cherrypy/_cprequest.py",
> line 63, in __call__
>return self.callback(**self.kwargs)
> File "build/bdist.macosx-10.10-intel/egg/ws4py/server/cherrypyserver.py",
> line 200, in upgrade
>ws_conn = get_connection(request.rfile.rfile)
> File "build/bdist.macosx-10.10-intel/egg/ws4py/compat.py", line 43, in
> get_connection
>return fileobj._sock
> AttributeError: 'KnownLengthRFile' object has no attribute '_sock'
> [28/Oct/2015:08:18:48] HTTP
> Request Headers:
> PRAGMA: no-cache
> COOKIE: autoTabEnabled=true; fleetStatusFilterCompany=7H;
> fleetStatusFilterLocation=ALL; fleetStatusRefreshInterval=5; inputNumLegs=5;
> session_id=5c8303896aff419c175c79dfadbfdc9d75e6c45a
> UPGRADE: websocket
> HOST: flbubble.ravnalaska.net:8088
> ORIGIN: http://flbubble.ravnalaska.net
> CONNECTION: Upgrade
> CACHE-CONTROL: no-cache
> SEC-WEBSOCKET-VERSION: 13
> SEC-WEBSOCKET-EXTENSIONS: x-webkit-deflate-frame
> USER-AGENT: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1)
> AppleWebKit/601.2.7 (KHTML, like Gecko) Version/9.0.1 Safari/601.2.7
> SEC-WEBSOCKET-KEY: Szh6Uoe+WzqKR1DgW8JcXA==
> Remote-Addr: 10.9.1.59
> [28/Oct/2015:08:18:48] HTTP
> Traceback (most recent call last):
> File
> "/Library/Python/2.7/site-packages/CherryPy-3.8.0-py2.7.egg/cherrypy/_cprequest.py",
> line 661, in respond
>self.hooks.run('before_request_body')
> File
> "/Library/Python/2.7/site-packages/CherryPy-3.8.0-py2.7.egg/cherrypy/_cprequest.py",
> line 114, in run
>raise exc
> AttributeError: 'KnownLengthRFile' object has no attribute '_sock'
>
> Disable tools.cpstats.on, and the sockets start working again. Is there some
> way I can fix this so I can use sockets as well as gather stats from my
> application? Thanks.
>
> ---
> Israel Brewster
> Systems Analyst II
> Ravn Alaska
> 5245 Airport Industrial Rd
> Fairbanks, AK 99709
> (907) 450-7293
> ---
>
> --
> https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: teacher need help!
I am having the same problem that we experienced earlier (see below). This student was exploring random numbers in Python. She named her program random which caused confusion for her computer. We deleted the file, but still had the problem. I removed Python from the machine. When I tried to reinstall, I got the attached error message. Now it won't even install. Any suggestions would be greatly appreciated! Thanks, Geneva Geneva Storey Fulton High School Spanish, Mathematics Bulldog Academy From: Storey, Geneva Sent: Tuesday, October 20, 2015 11:25 AM To: Tim Golden Cc: python-list@python.org Subject: Re: teacher need help! FYI-We formatted the machines, reinstalling everything, including Python. I works with no problems now. Confusing that this would happen on 3 out of 13 machines. Just letting you know, all is well. Thank you for your help! Geneva Geneva Storey Fulton High School Spanish, Mathematics Bulldog Academy From: Tim Golden Sent: Monday, October 19, 2015 3:39 AM To: Storey, Geneva Cc: python-list@python.org Subject: Re: teacher need help! On 19/10/2015 02:32, Storey, Geneva wrote: > Same issue! See attached. > Thanks! Geneva -- please try to post text, not pictures. Just use the mouse to cut-and-paste the entirety of the text from that window into an email. Otherwise some of the people who are trying to help you can't actually see what the problem is! [ Traceback show the same error coming from: c:\windows\system32\turtle.py ] This is a bit more tricky than it appears. If you're running on 64-bit Windows (which I can't tell from your screenshot) but your Python installation is 32-bit (which it is) then the folder which Python sees as "c:\windows\system32" is not the same folder which the normal Windows Explorer sees as "c:\windows\system32". Can you try going to this folder in Explorer: C:\windows\SysWOW64 and see if there's a turtle.py file there? If there is, move or delete it and try again. If that still doesn't work, can you tell us which version of Windows you're running, and whether it's 32 or 64-bit, please? If you're not sure how to get that information, try following the instructions here: http://ramblings.timgolden.me.uk/2015/10/08/what-windows-version-am-i-running/ TJG -- https://mail.python.org/mailman/listinfo/python-list
Re: What does “grep” stand for?
Am 04.11.15 um 19:24 schrieb Ben Finney: The name is a mnemonic for a compound command in ‘ed’ [0], a text editor that pre-dates extravagant luxuries like “presenting a full screen of text at one time”. [... lots of fun facts ...] Here is another fun fact: The convincing UI of ed was actually so widely applied, that even Microsoft included a similar editor into MSDOS, called EDLIN. EDLIN, of course, was a bastardized version of ed that could do much less and also lacked regular expressions. Needless to say that the mighty "VIsual" editor was out 5 years before MSDOS shipped EDLIN as the only editor... In contrast to ed, the stream editor "sed" is used multiple times avery day in a typical Unix session inside shell scripts to perform automated text processing tasks, including regex replacement. Christian -- https://mail.python.org/mailman/listinfo/python-list
any practise site about python?
hi guys. i am computer engineering student and i want to practise the lectures that i saw at school. for example dictionaries tuples or some other topics. i know eulerproject but it is hard for starting. do you know any exercise sites for students or beginners -- https://mail.python.org/mailman/listinfo/python-list
Re: What does “grep” stand for? (was: Regular expressions)
On 2015-11-05 05:24, Ben Finney wrote: > A very common command to issue, then, is “actually show me the line > of text I just specified”; the ‘p’ (for “print”) command. > > Another very common command is “find the text matching this pattern > and perform these commands on it”, which is ‘g’ (for “global”). The > ‘g’ command addresses text matching a regular expression pattern, > delimited by slashes ‘/’. > > So, for users with feeble human brains incapable of remembering > perfectly the entire content of the text while it changes and > therefore not always knowing exactly which lines they wanted to > operate on without seeing them all the time, a very frequent > combination command is: > > g/RE/p Though since the default action for g/ is to print the line, I've always wondered why the utility wasn't named just "gre" $ ed myfile.txt g/re [matching lines follow] q $ -tkc (the goofball behind https://twitter.com/ed1conf ) -- https://mail.python.org/mailman/listinfo/python-list
Re: pycrypto
Can u give me a suited solution that simply works for me? > http://stackoverflow.com/questions/11405549/how-do-i-install-pycrypto-on-windows Voidspace only has Python 3.3. They are usually behind some minor versions. The only good way to do this is to compile it from sources. Unfortunately, not everbody has an MSVC license... I find it **very** annoying that every time I need to download binary PyCrypto for the latest CPython, I have to search for it on the net. Sometimes it cannot be found for a week. :-( For the OP's question, here is the relevant stackoverflow question: http://stackoverflow.com/questions/32800336/pycrypto-on-python-3-5 And here are some compiled versions that can be downloaded and installed with PIP: https://github.com/sfbahr/PyCrypto-Wheels Why don't we have binary packages for PyCrypto, uploaded to PyPi? It seems that there are persons who can compile it, but there are no official packagers. I would happily do it for others, but I don't have an MSVC license. :-( -- https://mail.python.org/mailman/listinfo/python-list
What does “grep” stand for? (was: Regular expressions)
Steven D'Aprano writes: > On Wednesday 04 November 2015 13:55, Dan Sommers wrote: > > > Its very name indicates that its default mode most certainly is > > regular expressions. > > I don't even know what grep stands for. “grep” stands for ‘g/RE/p’. The name is a mnemonic for a compound command in ‘ed’ [0], a text editor that pre-dates extravagant luxuries like “presenting a full screen of text at one time”. In an ‘ed’ session, the user is obliged to keep mental track of the current line in the text buffer, and even what that text contains during the session. Single-letter commands, with various terse parameters such as the range of lines or some text to insert, are issued at a command prompt one after another. For these reasons, the manual page describes ‘ed’ as a “line-oriented text editor”. Everything is done by specifying lines, blindly, to commands which then operate on those lines. The name of the ‘vi’ editor means “visual interface (to a text editor)”, to proudly declare the innovation of a full screen of text that updates content during the editing session. That was not available for users of ‘ed’. A very common command to issue, then, is “actually show me the line of text I just specified”; the ‘p’ (for “print”) command. Another very common command is “find the text matching this pattern and perform these commands on it”, which is ‘g’ (for “global”). The ‘g’ command addresses text matching a regular expression pattern, delimited by slashes ‘/’. So, for users with feeble human brains incapable of remembering perfectly the entire content of the text while it changes and therefore not always knowing exactly which lines they wanted to operate on without seeing them all the time, a very frequent combination command is: g/RE/p meaning “find lines forward from here that match the regular expression pattern “RE”, and do nothing to those lines except print them to standard output”. Wikipedia has useful pages on both ‘grep’ and ‘ed’ https://en.wikipedia.org/wiki/Grep> https://en.wikipedia.org/wiki/Ed_%28text_editor%29>. You can see a full specification of how the ‘ed’ interface is to behave as part of the “Open Group Base Specifications Issue 7”, which is the specification for Unix. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ed.html> See the manual for GNU ed which includes an example session to appreciate just how far things have come. https://www.gnu.org/software/ed/manual/ed_manual.html#Introduction-to-line-editing> Of course, if you yearn for the days of minimalist purity, nothing beats Ed, man! !man ed [0] The standard text editor. https://www.gnu.org/fun/jokes/ed-msg.txt> -- \ “If you can't annoy somebody there is little point in writing.” | `\—Kingsley Amis | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Unbuffered stderr in Python 3
Random832 wrote:
>The opposite of line buffering is not no buffering, but full
>(i.e. block) buffering, that doesn't get flushed until it runs
>out of space. TextIOWrapper has its own internal buffer, and its
>design apparently doesn't contemplate the possibility of using
>it with a raw FileIO object (which may mean that the posted code
>isn't guaranteed to work) or disabling buffering.
Hmmm. That even seems to cause trouble for sys.stderr.write
(in Python3 with a non-tty e.g. a piped output):
$ python2 -c 'import sys;sys.stderr.write("1\n");print("2")' 2>&1 | tee
1
2
$ python3 -c 'import sys;sys.stderr.write("1\n");print("2")' 2>&1 | tee
2
1
--
https://mail.python.org/mailman/listinfo/python-list
Re: pycrypto
On Wed, Nov 4, 2015 at 5:41 AM, Christoph Zallmann wrote: > Hey there, > > > > i tried using Python 3.5.0 in combination with pycrypto and everything i got > was crap. Really. I tried so many things, how to solve my problem - using > environment variables, vs 2015 and many more. With python 2.7 or even 3.4 i > heard it was no problem but using 3.5 all i got was one error message that > leads to the next error message. Can you tell me how to install python 3.5 > on Windows 10 with a working pycrpto on it? As well pip as easy_install > threw the same errors e.g. "No matching distribution found for pycrypto" or > > error: Setup script exyited with error: Unable to find vcvarsall.bat > > > > Can u give me a suited solution that simply works for me? http://stackoverflow.com/questions/11405549/how-do-i-install-pycrypto-on-windows -- https://mail.python.org/mailman/listinfo/python-list
Re: Regular expressions
On 2015-11-04 09:57, Peter Otten wrote: > Well, I didn't know that grep uses regular expressions by default. It doesn't help that grep(1) comes in multiple flavors: grep: should use BRE (Basic REs) fgrep: same as "grep -F"; uses fixed strings, no REs egrep: same as "grep -E"; uses ERE (Extended REs) grep -P: a GNUism to use PCREs (Perl Compatible REs) there's also an "rgrep" which is just "grep -r" which I find kinda silly/redundant. Though frankly I feel the same way about fgrep/egrep since they just activate a command-line switch. You get even crazier when you start adding zgrep/zegrep/zfgrep. -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Irregular last line in a text file, was Re: Regular expressions
On 2015-11-04 14:39, Steven D'Aprano wrote:
> On Wednesday 04 November 2015 03:56, Tim Chase wrote:
>> Or even more valuable to me:
>>
>> with open(..., newline="strip") as f:
>> assert all(not line.endswith(("\n", "\r")) for line in f)
>
> # Works only on Windows text files.
> def chomp(lines):
> for line in lines:
> yield line.rstrip('\r\n')
.rstrip() takes a string that is a set of characters, so it will
remove any \r or \n at the end of the string (so it works with
both Windows & *nix line-endings) whereas just using .rstrip()
without a parameter can throw away data you might want:
>>> "hello \r\n\r\r\n\n\n".rstrip("\r\n")
'hello '
>>> "hello \r\n\r\r\n\n\n".rstrip()
'hello'
-tkc
--
https://mail.python.org/mailman/listinfo/python-list
Re: Regular expressions
On 11/04/2015 01:57 AM, Peter Otten wrote:
> and then headed for the man page. Apparently there is a subset
> called "basic regular expressions":
>
> """> Basic vs Extended Regular Expressions
>In basic regular expressions the meta-characters ?, +, {, |, (,
>and ) lose their special meaning; instead use the backslashed
>versions \?, \+, \{, \|, \(, and \).
> """
Good catch. I think this must have been what my brain was thinking when
I commented about grep and regular expressions earlier. I checked the
man page but didn't read down far enough.
I was still technically wrong though.
It's neat to learn so much on these tangents that the python list goes
on frequently. Hope the OP is still lurking, reading all these comments,
though I suspect he's not.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Regular expressions
On Thu, Nov 5, 2015 at 1:38 AM, rurpy--- via Python-list wrote: > I'm afraid you are making a category error but perhaps that's in > part because I wasn't clear. I was not talking about computer > science. I was talking about human beings learning about computers. > Most people I know consider programming to be a higher level activity > than "using" a computer: editing, sending email etc. Many computer > users (not programmers) learn to use regular expressions as part > of using a computer without knowing anything about programming. > It was on that basis I called them more fundamental -- something > learned earlier which is expanded on and added to later. But you > have a bit of a point, perhaps "fundamental" was not the best choice > of word to communicate that. The "fundamentals" of something are its most basic functions, not its most basic uses. The most common use of a computer might be to browse the web, but the fundamental functionality is arithmetic and logic. Setting aside the choice of word, though, I still don't think regular expressions are a more basic use of computing than loops and conditionals. A regex can't be used for anything other than string matching; they exist for one purpose, and one purpose only: to answer the question "Does this string match this pattern?". Sure, you can abuse that into a primality check and other forms of crazy arithmetic, but it's not what they truly do. I also would not teach regexes to people as part of an "introduction to computing" course, any more than I would teach the use of Microsoft Excel, which some such courses have been known to do. (And no, it's not because of the Microsoftness. I wouldn't teach LibreOffice Calc either.) You don't need to know how to work a spreadsheet as part of the basics of computer usage, and you definitely don't need an advanced form of text search. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Regular expressions
On Wednesday, November 4, 2015 at 1:52:31 AM UTC-7, Steven D'Aprano wrote: > On Wednesday 04 November 2015 18:21, Christian Gollwitzer wrote: > > > What rurpy meant, was that regexes can surface to a computer user > > earlier than variables and branches; a user who does not go into the > > depth to actually program the machine, might still encounter them in a > > text editor or database engine. Even some web forms allow some limited > > form, like e.g. the DVD rental here or Google. > [...] > What *I* think that Rurpy means is that one can construct a mathematical > system based on pattern matching which is Turing complete, and therefore in > principle any problem you can solve using a program written in (say) Python, > C, Lisp, Smalltalk, etc, or execute on a CPU (or simulate in your head!) > could be written as a sufficiently complex regular expression. No, Christian was correct. -- https://mail.python.org/mailman/listinfo/python-list
Re: Regular expressions
On 11/03/2015 08:48 PM, Steven D'Aprano wrote: > On Wednesday 04 November 2015 11:33, rurpy wrote: > >>> Not quite. Core language concepts like ifs, loops, functions, >>> variables, slicing, etc are the socket wrenches of the programmer's >>> toolbox. Regexs are like an electric impact socket wrench. You can do >>> the same work without it, but in many cases it's slower. But you have to >>> learn the other hand tools first in order to really use the electric >>> driver properly (understanding torques, direction of threads, etc), lest >>> you wonder why you're breaking off so many bolts with the torque of the >>> impact drive. >> >> I consider regexs more fundemental > > I'm sure that there are people who consider the International Space Station > more fundamental than the lever, the wedge and the hammer, but they would be > wrong too. > > Given primitives for branching, loops and variables, you can build support > for regexes. Given regexes, how would you build support for variables? > > Of course, you could easily prove me wrong. All you would need to do to > demonstrate that regexes are more fundamental than branching, loops and > variables would be to demonstrate that the primitive operations available in > commonly used CPUs are regular expressions, and that (for example) C's for > loop and if...else are implemented in machine code as regular expressions, > rather than the other way around. I'm afraid you are making a category error but perhaps that's in part because I wasn't clear. I was not talking about computer science. I was talking about human beings learning about computers. Most people I know consider programming to be a higher level activity than "using" a computer: editing, sending email etc. Many computer users (not programmers) learn to use regular expressions as part of using a computer without knowing anything about programming. It was on that basis I called them more fundamental -- something learned earlier which is expanded on and added to later. But you have a bit of a point, perhaps "fundamental" was not the best choice of word to communicate that. Here is what I wrote: > I consider regexs more fundemental. One need not even be a programmer > to use them: consider grep, sed, a zillion editors, database query > languages, etc. I thought the context, which you removed even to the point cutting text from the very same line you quoted, made that clear but perhaps not. Indeed it is quite eye-opening when one does learn a little CS and discovers these things that were just a useful "feature" actually have a deep and profound theoretical basis. -- https://mail.python.org/mailman/listinfo/python-list
Re: Unbuffered stderr in Python 3
Wolfgang Maier writes: > Standard I/O streams are line-buffered only if interactive (i.e., > connected to a console), but block-buffered otherwise. That's not appropriate for stderr, nor is it justified by the argument that Terry Reedy cited earlier. I had assumed he was making an implicit claim that stderr is _always_ line-buffered, _even if_ it is not interactive. > What does sys.stderr.isatty() return? There are many situations in which a nominally interactive process might not have a "tty" for stderr on MS Windows. In an Emacs M-x shell buffer, in a cygwin terminal (for a non-cygwin python), etc. -- https://mail.python.org/mailman/listinfo/python-list
Re: Regular expressions
On 2015-11-04, Michael Torrie wrote: > On 11/03/2015 08:23 PM, Steven D'Aprano wrote: >> Grep can use regular expressions (and I do so with it regularly), but it's default mode is certainly not regular expressions ... >>> >>> Its very name indicates that its default mode most certainly is >>> regular expressions. >> >> I don't even know what grep stands for. General Regular Expression Parser (or somesuch) >> But I think what Michael may mean is that if you "grep foo", no regex >> magic takes place since "foo" contains no metacharacters. > > More likely I just don't know what I'm talking about. I must have > been thinking about something else (shell globbing perhaps). > > Certainly most of the times I've seen grep used, it's to look for a > word with no special metacharacters, as you say. Still a valid RE of > course. But I have learned to night I don't need to resort to grep -e > to use regular expressions. The -e turns on "enhanced" regexes which add a few more features to the regex language it parses. I've never been entirely sure if the -e regex language is backwards compatible with the default one or not... > At least with GNU grep, that's the default. Grep has always by default parsed its first command line argument (at least since v7 and Sys5). If you didn't want it treated as a regex, you had to specify -f. -- Grant Edwards grant.b.edwardsYow! I like your SNOOPY at POSTER!! gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: LU decomposition
> Hey, > > I have to write a LU-decomposition. My Code worked so far but (I want to > become better:) ) I want to ask you, if I could write this LU-decomposition > in a better way? Why can't you just use scipy for this? http://docs.scipy.org/doc/scipy-0.14.0/reference/generated/scipy.linalg.lu.html Do you really need to reinvent the wheel? -- https://mail.python.org/mailman/listinfo/python-list
Bugfixing python 3.5 asyncio
Hello, There is a bug in asyncio.Queue (https://github.com/python/asyncio/issues/268), which makes it unusable for us. It is fixed in master now. What is the easiest way to patch the asyncio bundled with python if I have to distribute it among 5 colleagues? It is used in our private module. I can think of: 1. Copy asyncio.queues into our package so it has a different name 2. Override sys.path Both look really strange. Is there anything else? Thanks, Dmitry Panteleev -- https://mail.python.org/mailman/listinfo/python-list
pycrypto
Hey there, i tried using Python 3.5.0 in combination with pycrypto and everything i got was crap. Really. I tried so many things, how to solve my problem - using environment variables, vs 2015 and many more. With python 2.7 or even 3.4 i heard it was no problem but using 3.5 all i got was one error message that leads to the next error message. Can you tell me how to install python 3.5 on Windows 10 with a working pycrpto on it? As well pip as easy_install threw the same errors e.g. "No matching distribution found for pycrypto" or error: Setup script exyited with error: Unable to find vcvarsall.bat Can u give me a suited solution that simply works for me? Thanks and greetings, Chris -- https://mail.python.org/mailman/listinfo/python-list
Re: Unbuffered stderr in Python 3
On 04.11.2015 11:43, Wolfgang Maier wrote:
On 04.11.2015 11:24, Steven D'Aprano wrote:
On Wed, 4 Nov 2015 07:19 pm, Wolfgang Maier wrote:
On 04.11.2015 04:18, Steven D'Aprano wrote:
This is one of the offending line from our code base:
print('<4>Suspicious answer "{}"!'.format(answer), file=sys.stderr)
So that ought to be terminated by a newline. And yet, the stderr output
doesn't show up until the program exits.
For me, that prints immediately. Where is your output going? Console,
file, ...?
Going to stderr, like the whole thread is about :-)
I see :), but seriously, what I meant was: is it going to the console
directly or is your code base redirecting sys.stderr to another buffered
object first?
Standard I/O streams are line-buffered only if interactive (i.e.,
connected to a console), but block-buffered otherwise.
What does sys.stderr.isatty() return?
--
https://mail.python.org/mailman/listinfo/python-list
Re: Regular expressions
Op 04-11-15 om 04:35 schreef Steven D'Aprano: > On Wednesday 04 November 2015 03:20, Chris Angelico wrote: > >> (So, >> too, are all the comments about using [-1] or string methods. But we >> weren't to know that.) > If MRAB could understand what he wanted, I'm sure most others could have > too. Yes, they were just to busy to try pushing the OP in an other direction, for them to answer the question. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: Unbuffered stderr in Python 3
On 04.11.2015 11:24, Steven D'Aprano wrote:
On Wed, 4 Nov 2015 07:19 pm, Wolfgang Maier wrote:
On 04.11.2015 04:18, Steven D'Aprano wrote:
This is one of the offending line from our code base:
print('<4>Suspicious answer "{}"!'.format(answer), file=sys.stderr)
So that ought to be terminated by a newline. And yet, the stderr output
doesn't show up until the program exits.
For me, that prints immediately. Where is your output going? Console,
file, ...?
Going to stderr, like the whole thread is about :-)
I see :), but seriously, what I meant was: is it going to the console
directly or is your code base redirecting sys.stderr to another buffered
object first?
The output does eventually show up written to the console, but only after
Python exits.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Unbuffered stderr in Python 3
On Wed, 4 Nov 2015 07:19 pm, Wolfgang Maier wrote:
> On 04.11.2015 04:18, Steven D'Aprano wrote:
>> On Wednesday 04 November 2015 09:25, Terry Reedy wrote:
>>
>>> On 11/3/2015 10:42 AM, Chris Angelico wrote:
On Wed, Nov 4, 2015 at 2:00 AM, Random832
wrote:
> Nobody writes:
>
>> It's probably related to the fact that std{in,out,err} are Unicode
>> streams.
>
> There's no fundamental reason a Unicode stream should have to be line
> buffered. If it's "related", it's only in that an oversight was made
> in the course of making that change.
>>>
>>> The current behavior is not an 'oversight'. I was considered, decided,
>>> and revisited in https://bugs.python.org/issue13601. Guido:
>>> "Line-buffering should be good enough since in practice errors messages
>>> are always terminated by a newline." If not, print(part_line,
>>> file=sys.stderr, flush=True) works for the unusual case.
>>
>> This is one of the offending line from our code base:
>>
>> print('<4>Suspicious answer "{}"!'.format(answer), file=sys.stderr)
>>
>> So that ought to be terminated by a newline. And yet, the stderr output
>> doesn't show up until the program exits.
>>
>
> For me, that prints immediately. Where is your output going? Console,
> file, ...?
Going to stderr, like the whole thread is about :-)
The output does eventually show up written to the console, but only after
Python exits.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: Creating PST files using Python
On 03/11/2015 22:12, Chris Angelico wrote:
> On Wed, Nov 4, 2015 at 6:09 AM, Anthony Papillion
> wrote:
>> Does anyone know of a module that allows the wiring of Outlook PST
>> files using Python? I'm working on a project that will require me
>> to migrate 60gb of maildir mail (multiple accounts) to Outlook.
I don't know if this is quite what you were after but, if automating
Outlook is an option (ie using its COM object model), the code below is
an *extremely* Q&D approach to adding a PST and copying the messages in
a mbox one by one.
Obviously I've done just enough to show that it's viable, and none of
the more complicated work around conversation ids, multipart messages etc.
TJG
#!python3
import os, sys
import gzip
import mailbox
import urllib.request
import win32com.client
dispatch = win32com.client.gencache.EnsureDispatch
const = win32com.client.constants
PST_FILEPATH =
os.path.abspath(os.path.join(os.path.expandvars("%APPDATA%"),
"scratch.pst"))
if os.path.exists(PST_FILEPATH):
os.remove(PST_FILEPATH)
ARCHIVE_URL =
"https://mail.python.org/pipermail/python-list/2015-November.txt.gz";
MBOX_FILEPATH = "archive.mbox"
def download_archive(url, local_mbox):
with gzip.open(urllib.request.urlopen(url)) as archive:
with open(local_mbox, "wb") as f:
print("Writing %s to %s" % (url, local_mbox))
f.write(archive.read())
def copy_archive_to_pst(mbox_filepath, pst_folder):
archive = mailbox.mbox(mbox_filepath)
for message in archive:
print(message.get("Subject"))
pst_message = pst_folder.Items.Add()
pst_message.Subject = message.get("Subject")
pst_message.Sender = message.get("From")
pst_message.Body = message.get_payload()
pst_message.Move(pst_folder)
pst_message.Save()
def find_pst_folder(namespace, pst_filepath):
for store in dispatch(mapi.Stores):
if store.IsDataFileStore and store.FilePath == PST_FILEPATH:
return store.GetRootFolder()
download_archive(ARCHIVE_URL, MBOX_FILEPATH)
outlook = dispatch("Outlook.Application")
mapi = outlook.GetNamespace("MAPI")
pst_folder = find_pst_folder(mapi, PST_FILEPATH)
if not pst_folder:
mapi.AddStoreEx(PST_FILEPATH, const.olStoreDefault)
pst_folder = find_pst_folder(mapi, PST_FILEPATH)
if not pst_folder:
raise RuntimeError("Can't find PST folder at %s" % PST_FILEPATH)
copy_archive_to_pst(MBOX_FILEPATH, pst_folder)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Irregular last line in a text file, was Re: Regular expressions
On 4 November 2015 at 03:39, Steven D'Aprano wrote: > > Better would be this: > > def chomp(lines): > for line in lines: > yield line.rstrip() # remove all trailing whitespace > > > with open(...) as f: > for line in chomp(f): ... with open(...) as f: for line in map(str.rstrip, f): ... -- Oscar -- https://mail.python.org/mailman/listinfo/python-list
Re: Regular expressions
Michael Torrie wrote:
> On 11/03/2015 08:23 PM, Steven D'Aprano wrote:
Grep can use regular expressions (and I do so with it regularly), but
it's default mode is certainly not regular expressions ...
>>>
>>> Its very name indicates that its default mode most certainly is regular
>>> expressions.
>>
>> I don't even know what grep stands for.
>>
>> But I think what Michael may mean is that if you "grep foo", no regex
>> magic takes place since "foo" contains no metacharacters.
>
> More likely I just don't know what I'm talking about. I must have been
> thinking about something else (shell globbing perhaps).
>
> Certainly most of the times I've seen grep used, it's to look for a word
> with no special metacharacters, as you say. Still a valid RE of course.
> But I have learned to night I don't need to resort to grep -e to use
> regular expressions. At least with GNU grep, that's the default.
Well, I didn't know that grep uses regular expressions by default.
I tried Tim's example
$ seq 5 | grep '1*'
1
2
3
4
5
$
which surprised me because I remembered that there usually weren't any
matching lines when I invoked grep instead of egrep by mistake. So I tried
another one
$ seq 5 | grep '[1-3]+'
$
and then headed for the man page. Apparently there is a subset called "basic
regular expressions":
"""
Basic vs Extended Regular Expressions
In basic regular expressions the meta-characters ?, +, {, |, (,
and ) lose their special meaning; instead use the backslashed
versions \?, \+, \{, \|, \(, and \).
"""
--
https://mail.python.org/mailman/listinfo/python-list
Re: Regular expressions
On Wednesday 04 November 2015 18:21, Christian Gollwitzer wrote: > What rurpy meant, was that regexes can surface to a computer user > earlier than variables and branches; a user who does not go into the > depth to actually program the machine, might still encounter them in a > text editor or database engine. Even some web forms allow some limited > form, like e.g. the DVD rental here or Google. What Rurpy meant, only Rurpy can say, but I doubt that is what he is talking about. By that logic, a full-screen high-def 3D first-person shooter game with an advanced AI is "more fundamental" than an assembly language branch operation, because there are people who play computer games without doing assembly programming. In context, Michael suggested that programmers should learn the basic fundamentals of their chosen language, such as variables, for-loops and branching, before regexes -- which Rurpy then disagreed with, claiming that regexes are more fundamental than those basic operations. What *I* think that Rurpy means is that one can construct a mathematical system based on pattern matching which is Turing complete, and therefore in principle any problem you can solve using a program written in (say) Python, C, Lisp, Smalltalk, etc, or execute on a CPU (or simulate in your head!) could be written as a sufficiently complex regular expression. I think he is *technically wrong*, if by "regex" we mean actual regular expressions. Perl, and Python, regexes are strictly more powerful than regular expressions (despite the name). I know that Perl regexes are Turing complete (mainly because they can call out to the Perl interpreter), I'm not sure about Python regexes. But I also think that Rurpy is *not even wrong* if he means Perl or Python regexes. The (entirely theoretical) ability to solve a problem like "What is pi to the power of the first prime number larger than 97531000?" using a regex doesn't make regexes more fundamental than variables, branches and loops. It just makes them an alternative computing paradigm -- one which is *exponentially* more difficult to use than the standard paradigms of functional, procedural, OOP, etc. for anything except the limited subset of pattern matching problems they were created for. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: Is it ok to install python binaries on a network drive?
On 10/29/2015 01:07 PM, Steven D'Aprano wrote: My question is: what will happen when about 20 students will do the same >at the same time? I know too little about what's going under the hood >with an "import X" command to be able to predict problems that might >occur. I think it should be fine. Dear all, I just wanted to report that everything worked fine. It wasn't even too slow. I find it a quite elegant solution after all for all the students to have the same working environment. Thanks! Fabien -- https://mail.python.org/mailman/listinfo/python-list
Re: Unbuffered stderr in Python 3
On 04.11.2015 04:18, Steven D'Aprano wrote:
On Wednesday 04 November 2015 09:25, Terry Reedy wrote:
On 11/3/2015 10:42 AM, Chris Angelico wrote:
On Wed, Nov 4, 2015 at 2:00 AM, Random832 wrote:
Nobody writes:
It's probably related to the fact that std{in,out,err} are Unicode
streams.
There's no fundamental reason a Unicode stream should have to be line
buffered. If it's "related", it's only in that an oversight was made in
the course of making that change.
The current behavior is not an 'oversight'. I was considered, decided,
and revisited in https://bugs.python.org/issue13601. Guido:
"Line-buffering should be good enough since in practice errors messages
are always terminated by a newline." If not, print(part_line,
file=sys.stderr, flush=True) works for the unusual case.
This is one of the offending line from our code base:
print('<4>Suspicious answer "{}"!'.format(answer), file=sys.stderr)
So that ought to be terminated by a newline. And yet, the stderr output
doesn't show up until the program exits.
For me, that prints immediately. Where is your output going? Console,
file, ...?
--
https://mail.python.org/mailman/listinfo/python-list
