Re: help with regex
Peter Otten <__pete...@web.de> writes:
> >>> pattern = re.compile("(\d+)$")
> >>> match = pattern.search( "LINE: 235 : Primary Shelf Number (attempt 1): 1")
> >>> match.group()
> '1'
An alternative way to accomplish the above using the ‘match’ method::
>>> import re
>>> pattern = re.compile("^.*:(? *)(\d+)$")
>>> match = pattern.match("LINE: 235 : Primary Shelf Number (attempt 1): 1")
>>> match.groups()
('1',)
> See
Right. Always refer to the API documentation for the API you're
attempting to use.
--
\“Without cultural sanction, most or all of our religious |
`\ beliefs and rituals would fall into the domain of mental |
_o__) disturbance.” —John F. Schumaker |
Ben Finney
--
https://mail.python.org/mailman/listinfo/python-list
Re: How do I check if a string is a prefix of any possible other string that matches a given regex.
Le mercredi 8 octobre 2014 01:40:11 UTC+2, MRAB a écrit : > If you're not interested in generating an actual regex, but only in > > matching the prefix, then it sounds like you want "partial matching". > > > > The regex module supports that: > > > > https://pypi.python.org/pypi/regex Wow, thanks a lot! That really helps me. -- https://mail.python.org/mailman/listinfo/python-list
Re: operator module functions
For me it makes sense. operator.add should be used in a "global" context (I don't know how to express it otherwise). So you provide it with the two values that you want to add. The .__add__ variants are bound to a particular instance and you provide it with a single value that you want to add. You also need the dunder versions when you want to implement addition for user defined types. So although they are similar, I do believe they have slightly different uses. As an example, you cannot use the dunder versions for literals. >> 2.__add__(3) # Oops, does not work >> a = 2 >> a.__add__(3) 5 >> import operator >> operator.add(2,3) # Fine I also think operator.add versus .__add__ is equivalent to the global getattr() and .__getattr__. Marco -- https://mail.python.org/mailman/listinfo/python-list
[RELEASE] Python 3.4.2 is now available
On behalf of the Python development community and the Python 3.4 release team, I'm pleased to announce the availability of Python 3.4.2. Python 3.4.2 has many bugfixes and other small improvements over 3.4.1. One new feature for Mac OS X users: the OS X installers are now distributed as signed installer package files compatible with the OS X Gatekeeper security feature. You can download it here: https://www.python.org/download/releases/3.4.2 May the road rise up to meet you, //arry/ -- https://mail.python.org/mailman/listinfo/python-list
Re: operator module functions
(You didn't include any context in your post. Please quote as much text as would be helpful; it's the easiest way to show what you're talking about.) On Wed, Oct 8, 2014 at 7:46 PM, wrote: > For me it makes sense. operator.add should be used in a "global" context > (I don't know how to express it otherwise). So you provide it with the > two values that you want to add. The .__add__ variants are bound to a > particular instance and you provide it with a single value that you want > to add. What Steven's talking about is this: >>> operator.add is operator.__add__ True It's the exact same function, just accessed with a different name. > As an example, you cannot use the dunder versions for literals. > >>> 2.__add__(3) # Oops, does not work >>> a = 2 >>> a.__add__(3) > 5 That's actually just a syntactic issue with integers and the dot. It works fine if you use any other form of literal, or if you put a space between the digits and the dot, or use parentheses, or anything; this is the case with all methods off integers, not just dunder ones. >>> 2 .__add__(3) 5 >>> (2).__add__(3) 5 >>> 2.0.__add__(3.0) 5.0 The object is exactly the same whether you reference the literal '2' or the name 'a' that you've bound to it, so its methods must by definition all be there. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.4.1 on W2K?
random832 wrote on Tue Oct 7 22:33:23 CEST 2014 >On Tue, Oct 7, 2014, at 16:27, Michael Torrie wrote: >>That's really interesting. I looked briefly at the page. How does your python extension work with xywrite? Does it manipulate xywrite >>documents >>or does it tie in at runtime with Xywrite somehow? If so, how >>does it do >>this? Crossing the divide into a 16-bit app is pretty >>impressive. > I >>assume that it uses temporary files (or pipes, don't know if DOS can > do this), and that DOS programs can execute windows programs with int > 21/4B. Yup, files. In other words, rubber bands and chewing gum, but it works nicely. Here's a short screen video of an "XPyL" routine that compiles a sorted list of all unique words in a text file and reports average word length. Subject file is the Gutenberg e-file of Moby-Dick, a 1.2MB text file. It's fast. http://youtu.be/88isdo-Cch4 BTW, this is Python 3.2.5 running on W2K in VirtualBox. Pal A.-- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.4.1 on W2K
Here's another quick one -- under 30 secs. -- and then I'll revert to lurker status. It's one of my favorites: "Veritas" wine & liquor search. (Teetotalers, avert your eyes.) http://youtu.be/jDtm4z7kqyI Pal A. -- https://mail.python.org/mailman/listinfo/python-list
Re: ruby instance variable in python
The end result of a confusing sentence with no > > context is that I have no idea what you are trying to say. Could you try > > explaining again please? > > > Steven No problem my reply from phone at work a little confusing. So trying to determine what this does. def ins_var @ins_var ||= nil end In particular I was guessing at this. @ins_var ||= nil Which I have now found on Rubyinside http://www.rubyinside.com/21-ruby-tricks-902.html >From there 7 - Cut down on local variable definitions Instead of defining a local variable with some initial content (often just an empty hash or array), you can instead define it "on the go" so you can perform operations on it at the same time: (z ||= []) << 'test' 2009 Update: This is pretty rancid, to be honest. I've changed my mind; you shouldn't be doing this :) So now that I know this I am still further lost to the point of the initially posted code so my kubuntu has ruby so I have run it, and honestly I need further definition on what that code was trying to acheive. sayth@sayth-TravelMate-5740G:~/scripts$ ruby --version ruby 1.9.3p484 (2013-11-22 revision 43786) [x86_64-linux] sayth@sayth-TravelMate-5740G:~/scripts$ irb irb(main):001:0> (z ||= []) << 'test' => ["test"] irb(main):002:0> @ins_var ||= nil => nil irb(main):003:0> def ins_var irb(main):004:1> @ins_var ||= nil irb(main):005:1> end => nil irb(main):006:0> def m irb(main):007:1> @ins_var = "val" irb(main):008:1> end => nil irb(main):009:0> def m2 irb(main):010:1> ins_var #=> "val" irb(main):011:1> end => nil irb(main):012:0> m => "val" irb(main):013:0> m2 => "val" Sayth -- https://mail.python.org/mailman/listinfo/python-list
Re: Pythonic way to iterate through multidimensional space?
On 10/7/2014 1:01 PM, Ned Batchelder wrote: On 10/7/14 2:10 AM, Gelonida N wrote: Disadvantage of itertools.product() is, that it makes a copy in memory. Reason ist, that itertools also makes products of generators (meaning of objects, that one can't iterate several times through) There are two use cases, that I occasionaly stumble over: One is making the product over lists(), product( list_of_lists ) ex: product( [ [1,2,3], ['A','B'], ['a', 'b', 'c'] ] ) the other one making a product over a list of functions, which will create generators ex: product( [ lambda: [ 'A', 'B' ], lambda: xrange(3) ] ) I personally would also be interested in a fast generic solution that can iterate through an N-dimensional array and which does not duplicate the memory or iterate through a list of generator-factories or however this would be called. itertools.product makes a copy of the sequences passed in, but it is a shallow copy. It doesn't copy the objects in the sequences. It also doesn't store the entire product. If you are calling product(j, k, l, m, n), where len(j)==J, the extra memory is J+K+L+M+N, which is much smaller than the number of iterations product will produce. Are you sure that much extra memory use is a problem? How large are your lists that you are product'ing together? Thanks for the clarification. You are right. Consumption of a shallow copy of each iterator, should not be a problem in the cases that I encountered so far. I don't understand your point about a list of functions that create generators? What is the problem there? The idea was to even avoid the creation of a shallow copy, by having a function, that will return the same generator over and over again (thus no need for shallow copy) -- https://mail.python.org/mailman/listinfo/python-list
how to add custom importer after the normal imports
Hi, I just read about sys.meta_path, which allows to install custom importers *BEFORE* the default importers. However I have a use case where I would like to add a custom importer *AFTER* all other import methods have failed. Does anybody know how to do this. One way of implementing this would be to add the default importer as first entry in sys.meta_path. My only problem is, that I don't know how to create a 'default-importer', such that I can add it into sys.meta_path Thanks in advance for any suggestions -- https://mail.python.org/mailman/listinfo/python-list
Re: operator module functions
marco.naw...@colosso.nl wrote: > For me it makes sense. operator.add should be used in a "global" context > (I don't know how to express it otherwise). So you provide it with the > two values that you want to add. The .__add__ variants are bound to a > particular instance and you provide it with a single value that you want > to add. That's not correct. You're misunderstanding me, I'm not talking about the special "dunder" methods on classes, e.g. (2).__add__(3) -> 5. I'm talking about *functions* in the operator module: py> import operator py> operator.add(2, 3) 5 py> operator.__add__(2, 3) 5 According to the documentation, operator.__add__ is the "official" function, and operator.add is just there for convenience. Neither of them is the special method __add__. But it seems that nobody uses the official operator.__add__ function, and Terry Reedy says there are no tests for it. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Another time question
On 2014-10-07, Seymore4Head wrote: > I never really cared enough to ask anyone, but something like my cable > bill is 98$ a month. Do companies (in general) consider a month every > 30 days or every time the 14th comes around? Either/both. My pre-pay T-Mobile account is every $30 every 30 days, but they call it "$30 a month". The T-Mobile post-pay contracts were per calendar month, and the payment was due on the same date every month. -- Grant Edwards grant.b.edwardsYow! Can you MAIL a BEAN at CAKE? gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Practice question
On Tuesday, October 7, 2014 2:19:39 AM UTC+5:30, Steven D'Aprano wrote: > I have fewer issues with your conclusion and analogy than I do with the > basic premise that there is a connection between Seymore's problem here > and the use, or non-use, of print in the interactive interpreter. I don't > see how replacing interactive use and/or the use of print with functions > containing return statements would help Seymore. The issue is not only that print is bad but that the interpreter is good for learning and trying out. Are these two really unconnected. Lets see... One can - use print without the interpreter - use the interpreter without print - use both But can one use neither? [Assuming telepathy/ESP etc is disallowed] So pushing beginners away from print can push them up the learning curve more quickly -- https://mail.python.org/mailman/listinfo/python-list
Re: Practice question
On Thu, Oct 9, 2014 at 3:14 AM, Rustom Mody wrote: > The issue is not only that print is bad but that the interpreter is > good for learning and trying out. > > Are these two really unconnected. Lets see... One can > > - use print without the interpreter > - use the interpreter without print > - use both > > But can one use neither? [Assuming telepathy/ESP etc is disallowed] > > So pushing beginners away from print can push them up the learning > curve more quickly (Please be more clear with your terminology; running Python scripts is still using the interpreter, it's just not using *interactive* Python. What you're saying above is all about Python's interactive mode.) Your conclusion doesn't obviously follow from your preceding statements. How does pushing people away from print push them up? Which way is "up"? Is it "up" to move from interactive Python to scripts run from the command line? Or is that down? How does the avoidance of print push anyone anywhere, anyway? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Practice question
On Wed, Oct 8, 2014 at 11:14 AM, Rustom Mody wrote: > So pushing beginners away from print can push them up the learning > curve more quickly Or more quickly discourage them. I still use print for all sorts of things. In my opinion, there is often no need for fancy loggers, str.format, or the write method of file-like objects. Print will often get you a "good enough" result faster than the other means. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Practice question
On Wednesday, October 8, 2014 9:58:11 PM UTC+5:30, Skip Montanaro wrote: > On Wed, Oct 8, 2014 at 11:14 AM, Rustom Mody wrote: > > So pushing beginners away from print can push them up the learning > > curve more quickly > Or more quickly discourage them. I still use print for all sorts of > things. In my opinion, there is often no need for fancy loggers, > str.format, or the write method of file-like objects. Print will often > get you a "good enough" result faster than the other means. Well I'm not talking of people like you!! Nor of more sophisticated tools than print. I am talking of the fact that an absolute basic sine qua non for beginners is to be able to structure programs: - breaking up a complex expression into sub-expressions - abstracting out a sub-expression into a function with an appropriate parameterization - inverses of the above when the current cut is sub-optimal etc etc... what is nowadays fashionably called 'refactoring' And for that the noob needs to learn to write return-ing function where he currently writes a print-ing function. -- https://mail.python.org/mailman/listinfo/python-list
Re: "High water" Memory fragmentation still a thing?
Chris Angelico wrote: > Sure, and that's all well and good. But what I just cited there *is* a > shipping product. That's a live server that runs a game that I'm admin > of. So it's possible to do without the resource safety net of periodic > restarts. Nice that the non-Python server you administer stayed up for 88 weeks, but that doesn't really have anything to do with the issue here. The answer to the OP's title question is "yes", high-water memory fragmentation is a real thing, in most platforms including CPython. The cited article tells of Celery hitting the problem, and the working solution was to "roll the celery worker processes". That doesn't mean to tell a human administrator to regularly restart the server. It's programmatic and it's a reasonably simple and well-established design pattern. > > For an example see the Apache HTTP daemon, particularly the classic > > pre-forking server. There's a configuration parameter, > > "MaxRequestsPerChild", that sets how many requests a process should answer > > before terminating. > > That assumes that requests can be handled equally by any server > process - and more so, that there are such things as discrete > requests. That's true of HTTP, but not of everything. It's true of HTTP and many other protocols because they were designed to support robust operation even as individual components may fail. > And even with > HTTP, if you do "long polls" [1] then clients might remain connected > for arbitrary lengths of time; either you have to cut them off when > you terminate the server process (hopefully that isn't too often, or > you lose the benefit of long polling), or you retain processes for > much longer. If you look at actual long-polling protocols, you'll see that the server occasionally closing connections is no problem at all. They're actually designed to be robust even against connections that drop without proper shutdown. > Restarting isn't necessary. It's like rebooting a computer: people get > into the habit of doing it, because it "fixes problems", but all that > means is that it allows you to get sloppy with resource management. CPython, and for that matter malloc/free, have known problems in resource management, such as the fragmentation issue noted here. There are more. Try a Google site search for "memory leak" on http://bugs.python.org/. Do you think the last memory leak is fixed now? >From what I've seen, planned process replacement is the primary techniques to >support long-lived mission-critical services in face of resource management >flaws. Upon process termination the OS recovers the resources. I love CPython, >but on this point I trust the Linux kernel much more. -- --Bryan -- https://mail.python.org/mailman/listinfo/python-list
Re: operator module functions
On 10/8/2014 6:57 AM, Steven D'Aprano wrote: According to the documentation, operator.__add__ is the "official" function, and operator.add is just there for convenience. You are paraphrasing "The function names are those used for special class methods; variants without leading and trailing __ are also provided for convenience." But then there is the following: 10.3.1. Mapping Operators to Functions This table shows how abstract operations correspond to operator symbols in the Python syntax and the functions in the operator module. Operation Syntax Function Additiona + b add(a, b) etc, using the 'convenient' names. I would like to deprecate and eventually remove the dunder names. To me, the duplication is not 'convenient'. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
strange numpy behaviour
This does not look right: dilbert@gtrojan> python3.4 Python 3.4.1 (default, Jul 7 2014, 15:47:25) [GCC 4.8.3 20140624 (Red Hat 4.8.3-1)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import numpy as np >>> a=np.ma.array([0, 1], dtype=np.int8, mask=[1, 0]) >>> a masked_array(data = [-- 1], mask = [ True False], fill_value = 99) >>> a.data array([0, 1], dtype=int8) >>> a.filled() array([63, 1], dtype=int8) <--- Why 63? >>> What do you think? George -- https://mail.python.org/mailman/listinfo/python-list
Re: strange numpy behaviour
On Wed, Oct 8, 2014 at 10:29 AM, George Trojan wrote: > This does not look right: > > dilbert@gtrojan> python3.4 > Python 3.4.1 (default, Jul 7 2014, 15:47:25) > [GCC 4.8.3 20140624 (Red Hat 4.8.3-1)] on linux > Type "help", "copyright", "credits" or "license" for more information. import numpy as np a=np.ma.array([0, 1], dtype=np.int8, mask=[1, 0]) a > masked_array(data = [-- 1], > mask = [ True False], >fill_value = 99) > a.data > array([0, 1], dtype=int8) a.filled() > array([63, 1], dtype=int8) <--- Why 63? > > What do you think? The datatype is int8, the fill value is the default of 99, and 99 & 0xff == 63. -- https://mail.python.org/mailman/listinfo/python-list
Re: operator module functions
On 10/08/2014 12:09 PM, Terry Reedy wrote: On 10/8/2014 6:57 AM, Steven D'Aprano wrote: According to the documentation, operator.__add__ is the "official" function, and operator.add is just there for convenience. You are paraphrasing "The function names are those used for special class methods; variants without leading and trailing __ are also provided for convenience." But then there is the following: 10.3.1. Mapping Operators to Functions This table shows how abstract operations correspond to operator symbols in the Python syntax and the functions in the operator module. Operation Syntax Function Addition a + b add(a, b) etc, using the 'convenient' names. I would like to deprecate and eventually remove the dunder names. To me, the duplication is not 'convenient'. LOL, no kidding! The main reason I bother using the operator module is for the readability of not seeing the dunders, and the writability of not having to type them. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: operator module functions
On Wed, Oct 8, 2014, at 15:38, Ethan Furman wrote: > LOL, no kidding! The main reason I bother using the operator module is > for the readability of not seeing the dunders, > and the writability of not having to type them. I'm not sure what situation you would have to type them (as opposed to simply a + b) that the operator module would help with. -- https://mail.python.org/mailman/listinfo/python-list
Re: operator module functions
On 10/8/2014 9:09 PM, Terry Reedy wrote: On 10/8/2014 6:57 AM, Steven D'Aprano wrote: According to the documentation, operator.__add__ is the "official" function, and operator.add is just there for convenience. You are paraphrasing "The function names are those used for special class methods; variants without leading and trailing __ are also provided for convenience." But then there is the following: 10.3.1. Mapping Operators to Functions This table shows how abstract operations correspond to operator symbols in the Python syntax and the functions in the operator module. Operation Syntax Function Addition a + b add(a, b) etc, using the 'convenient' names. I would like to deprecate and eventually remove the dunder names. To me, the duplication is not 'convenient'. I'd be curious about a proposal to obsolete the double underscore functions and just keep operator.add or to just keep the operator + For me they seem rather distinct, though they are interchangable in certain situations. Perhaps I got something wrong, but all dunder functions are 'magic' functions. Many of them mostly should ne used when when overloading behaviour or when creating a class which should implement operators. So for implemetation you use __add__ for using you use the operator + if you need a class MyClass(object): def __init__(self, x, y): self.x = x self.y = y # implements + for a certain type def __add__(self, other): return MyClass(self.x + other.x, self.y + other.y) def __repr__(self): return "(%f,%f)" % (self.x, self.y) a = MyClass(1,2) b = MyClass(4,5) print(a) print(b) print(a+b) # operator.add is identical to the + operator , # BUT it is a function and can thuss be # assigned to variables passed as parameter def dosomething(op, val1, val2): return op(val1, val2) print(dosomething(operator.add, 1, 2)) print(dosomething(operator.add, a, b)) -- https://mail.python.org/mailman/listinfo/python-list
Re: operator module functions
On Wed, Oct 8, 2014 at 3:05 PM, Gelonida N wrote: > On 10/8/2014 9:09 PM, Terry Reedy wrote: >> >> On 10/8/2014 6:57 AM, Steven D'Aprano wrote: >> >>> According to the documentation, operator.__add__ is the "official" >>> function, >>> and operator.add is just there for convenience. >> >> >> You are paraphrasing "The function names are those used for special >> class methods; variants without leading and trailing __ are also >> provided for convenience." But then there is the following: >> >> 10.3.1. Mapping Operators to Functions >> >> This table shows how abstract operations correspond to operator symbols >> in the Python syntax and the functions in the operator module. >> Operation Syntax Function >> Addition a + b add(a, b) >> >> etc, using the 'convenient' names. I would like to deprecate and >> eventually remove the dunder names. To me, the duplication is not >> 'convenient'. >> > > > I'd be curious about a proposal to obsolete the double underscore functions > and just keep operator.add or to just keep the operator + > > For me they seem rather distinct, though they are interchangable in certain > situations. > > Perhaps I got something wrong, but all dunder functions are 'magic' > functions. Many of them mostly should ne used when when overloading > behaviour or when creating a class which should implement operators. This isn't about the dunder *method* names. It's about the naming of the functions in the operator module, e.g. having both operator.add and operator.__add__ that are two names for the same function. -- https://mail.python.org/mailman/listinfo/python-list
Re: How do I check if a string is a prefix of any possible other string that matches a given regex.
jonathan.slend...@gmail.com wrote: For each non-accepting state, determine whether it has any transitions that lead in one or more steps to an accepting state. Modify the FSM so that each such state is also an accepting state. Thanks, I'll make every state of the FSM an accepting state. Not *every* state -- that will give you an FSM that accepts any string! -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: operator module functions
Chris Angelico wrote: operator.add is operator.__add__ True That doesn't always seem to have been the case, however. In Python 2.7 and 3.3, I get >>> operator.add is operator.__add__ False -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: operator module functions
[redirecting back to the list] On 10/08/2014 02:23 PM, random...@fastmail.us wrote: On Wed, Oct 8, 2014, at 15:53, Ethan Furman wrote: On 10/08/2014 12:49 PM, random...@fastmail.us wrote: On Wed, Oct 8, 2014, at 15:38, Ethan Furman wrote: LOL, no kidding! The main reason I bother using the operator module is for the readability of not seeing the dunders, and the writability of not having to type them. I'm not sure what situation you would have to type them (as opposed to simply a + b) that the operator module would help with. unittest springs to mind: self.assertRaises(TypeError, op.add, obj1, obj2) Er, my point is, that is not a situation where you would be able to use obj1.__add__ - you'd have to use the operator module *anyway*, and therefore aren't using it just to get the convenience of a non-dunder name. self.assertRaises(TypeError, lambda x, y: x+y, obj1, obj2) -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: operator module functions
On Wed, Oct 8, 2014 at 2:05 PM, Gelonida N wrote: > On 10/8/2014 9:09 PM, Terry Reedy wrote: > >> On 10/8/2014 6:57 AM, Steven D'Aprano wrote: >> >> According to the documentation, operator.__add__ is the "official" >>> function, >>> and operator.add is just there for convenience. >>> >> >> You are paraphrasing "The function names are those used for special >> class methods; variants without leading and trailing __ are also >> provided for convenience." But then there is the following: >> >> 10.3.1. Mapping Operators to Functions >> >> This table shows how abstract operations correspond to operator symbols >> in the Python syntax and the functions in the operator module. >> Operation Syntax Function >> Addition a + b add(a, b) >> >> etc, using the 'convenient' names. I would like to deprecate and >> eventually remove the dunder names. To me, the duplication is not >> 'convenient'. >> >> > > I'd be curious about a proposal to obsolete the double underscore > functions and just keep operator.add or to just keep the operator + > > For me they seem rather distinct, though they are interchangable in > certain situations. > > Perhaps I got something wrong, but all dunder functions are 'magic' > functions. Many of them mostly should ne used when when overloading > behaviour or when creating a class which should implement operators. > > print(dosomething(operator.add, 1, 2)) > print(dosomething(operator.add, a, b)) The thing being purposed to remove, is that you can also do: print(dosomething(operator.__add__, 1, 2)) print(dosomething(operator.__add__, a, b)) Not that fact that you can define __add__ in the class, or that "operator.add(a, b)" is the same as "a + b" (all of which are quite useful). Basically, the operator module has a "__add__" function in addition to a "add" function, and they are both identical (in fact, they are the same function object): >>> import operator >>> operator.add >>> operator.__add__ >>> operator.__add__ is operator.add True -- https://mail.python.org/mailman/listinfo/python-list
Re: operator module functions
random...@fastmail.us writes: > On Wed, Oct 8, 2014, at 15:38, Ethan Furman wrote: > > The main reason I bother using the operator module is for the > > readability of not seeing the dunders, and the writability of not > > having to type them. > > I'm not sure what situation you would have to type them (as opposed to > simply a + b) that the operator module would help with. Any situation where you need to refer to a function. ‘+’ is not a function, whereas ‘operator.add’ is. import operator import functools add_three = functools.partial(operator.add, 3) foo = list(range(10)) bar = map(add_three, foo) The above ‘map’ invocation – which is useful because it allows any arbitrary one-parameter function to be used – cannot be used with ‘+’, which is not a function. Likewise, ‘functools.partial’ requires a function, and ‘+’ is not a function. There are countless such uses for the functions in the ‘operator’ module. -- \ “It is the integrity of each individual human that is in final | `\examination. On personal integrity hangs humanity's fate.” | _o__) —Richard Buckminster Fuller, _Critical Path_, 1981 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
virtualenv question: include just a few site packages
virtualenv has the switch --system-site-packages (including all system site pacgaes) and the switch --no-site-packages (to expclude all site packages) Does anyone know an easy way to include just a few site-packages? for example (PySide, but not PyQt) The reason I'm asking is following. Some site packages are sometimes raher huge or sometimes refuse to compile on certain hosts. as these packages are already part of the site packages I'd like to include them. You might wonder why I care whether I have more site packages than I need. As long as I don't import them, I shouldn't care about it. If I really wanted to replace a version I could use pip install -U. However sometimes I'd like to have a test environment where want to be sure, that no module can find certain other modules. so they should not be visible. at the moment I make some experiments with pyinstaller and the module pythonqtbindings. and there I'd like to be sure that no PuQt files end up in the generated code. The only idea, that I have so far is to run virutalanv with --system-side-packages and to manually remove modules I don't want or to run virtualenv without this switch and to manually add links for site packages, taht I want. both options don't really feel right for me. Is there any other way? -- https://mail.python.org/mailman/listinfo/python-list
Re: operator module functions
On Thu, Oct 9, 2014 at 8:37 AM, Gregory Ewing wrote: > Chris Angelico wrote: > > operator.add is operator.__add__ >> >> True > > > That doesn't always seem to have been the case, however. > In Python 2.7 and 3.3, I get > operator.add is operator.__add__ > False Huh. So it is. rosuav@sikorsky:~$ python3 Python 3.5.0a0 (default:301b9a58021c, Oct 2 2014, 09:20:24) [GCC 4.7.2] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import operator >>> operator.add, operator.__add__ (, ) >>> rosuav@sikorsky:~$ python Python 2.7.3 (default, Mar 13 2014, 11:03:55) [GCC 4.7.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import operator >>> operator.add, operator.__add__ (, ) >>> Presumably they have the same code behind them, just different function names. But anyway, the fact that it doesn't throw back an AttributeError proves that both functions do at least exist. Learn something new every day! ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: operator module functions
On Wed, Oct 8, 2014 at 3:30 PM, Chris Angelico wrote: > > > > > > That doesn't always seem to have been the case, however. > > In Python 2.7 and 3.3, I get > > > operator.add is operator.__add__ > > False > > Huh. So it is. > > rosuav@sikorsky:~$ python3 > Python 3.5.0a0 (default:301b9a58021c, Oct 2 2014, 09:20:24) > [GCC 4.7.2] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> import operator > >>> operator.add, operator.__add__ > (, ) > >>> > rosuav@sikorsky:~$ python > Python 2.7.3 (default, Mar 13 2014, 11:03:55) > [GCC 4.7.2] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> import operator > >>> operator.add, operator.__add__ > (, ) > >>> > > Presumably they have the same code behind them, just different > function names. But anyway, the fact that it doesn't throw back an > AttributeError proves that both functions do at least exist. > > Learn something new every day! I only tried it in Python 3.4, and I got true. Perhaps it was optimized slightly after 3.3? Chris -- https://mail.python.org/mailman/listinfo/python-list
Re: how to add custom importer after the normal imports
On Wed, Oct 8, 2014 at 4:53 AM, Gelonida N wrote: > Hi, > > > I just read about sys.meta_path, which allows to install custom importers > *BEFORE* the default importers. > > However I have a use case where I would like to add a custom importer > *AFTER* all other import methods have failed. > > Does anybody know how to do this. > > One way of implementing this would be to add the default importer as first > entry in sys.meta_path. My only problem is, that I don't know how to create > a 'default-importer', such that I can add it into sys.meta_path As of CPython 3.3 the default importers are already in sys.meta_path, so you could just add your custom importer to the end. If you need to support earlier versions or alternate implementations then this may not be reliable. -- https://mail.python.org/mailman/listinfo/python-list
Re: operator module functions
On 10/8/2014 5:49 PM, Ethan Furman wrote: [redirecting back to the list] I'm not sure what situation you would have to type them (as opposed to simply a + b) that the operator module would help with. unittest springs to mind: self.assertRaises(TypeError, op.add, obj1, obj2) Er, my point is, that is not a situation where you would be able to use obj1.__add__ - you'd have to use the operator module *anyway*, and therefore aren't using it just to get the convenience of a non-dunder name. self.assertRaises(TypeError, lambda x, y: x+y, obj1, obj2) That works, but is a bit harder to type (given the import), more confusing to read (the extra ',' that does *not* delimit an argument) and adds an extra layer to the call stack with each call. The extra layer *could* make a difference in recursion. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: operator module functions
On 10/08/2014 03:46 PM, Terry Reedy wrote: On 10/8/2014 5:49 PM, Ethan Furman wrote: [redirecting back to the list] I'm not sure what situation you would have to type them (as opposed to simply a + b) that the operator module would help with. unittest springs to mind: self.assertRaises(TypeError, op.add, obj1, obj2) Er, my point is, that is not a situation where you would be able to use obj1.__add__ - you'd have to use the operator module *anyway*, and therefore aren't using it just to get the convenience of a non-dunder name. self.assertRaises(TypeError, lambda x, y: x+y, obj1, obj2) That works, but is a bit harder to type (given the import), more confusing to read (the extra ',' that does *not* delimit an argument) and adds an extra layer to the call stack with each call. The extra layer *could* make a difference in recursion. Indeed, thanks for the corrections. I was merely replying to the "have to use the operator module anyway" comment. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Toggle
I want to toggle between color="Red" and color="Blue" Here is one: if color == "Red": color = "Blue" else: color = "Red" Here is two: if x = "True" color = "Red" else: color="Blue" x= not x Others? -- https://mail.python.org/mailman/listinfo/python-list
Re:Toggle
Seymore4Head Wrote in message: > I want to toggle between color="Red" and color="Blue" > Here is one: > if color == "Red": > color = "Blue" > else: > color = "Red" > Here is two: > if x = "True" color = "Red" > else: > color="Blue" > x= not x > > Others? > One looks like it wrks and two looks like nonsense. Just what are you trying to ask? -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: Toggle
On 09/10/2014 01:11, Seymore4Head wrote: I want to toggle between color="Red" and color="Blue" Here is one: if color == "Red": color = "Blue" else: color = "Red" Here is two: if x = "True" color = "Red" else: color="Blue" x= not x Others? Here http://stackoverflow.com/questions/8381735/toggle-a-value-in-python but why couldn't you search in the first place? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Toggle
Seymore4Head wrote:
> I want to toggle between color="Red" and color="Blue"
> Here is one:
> if color == "Red":
> color = "Blue"
> else:
> color = "Red"
Apart from the horrible spelling of colour :-) that seems fine to me. You
might wish to include a comment:
# Assumes that color can only take the values "Red" or "Blue".
just before the toggle code. But even better than a comment is an assertion:
assert color in ("Red", "Blue")
if color == "Red":
color = "Blue"
else:
color = "Red"
This makes it a "checked comment" -- the primary purpose of the assert here
is as a comment, but the interpreter will by default actually check that it
is true (although that can be turned off by the user).
You can find out more about good, and bad, uses of assert here:
http://import-that.dreamwidth.org/676.html
> Here is two:
> if x = "True" color = "Red"
> else:
> color="Blue"
> x= not x
That gives SyntaxError. And it's wrong because you are confusing the
*string* "T r u e" with the constant True. It should be:
assert isinstance(x, bool)
if x: # don't write "if x == True" since that is redundant
color = 'Red'
else:
color = 'Blue'
x = not x
> Others?
color = ("Red", "Blue")[color == "Red"]
color = {"Red": "Blue", "Blue": "Red"}[color]
color = "Red" if color == "Blue" else "Blue"
There may be even more complicated, obscure or obfuscated versions possible.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: operator module functions
On 10/8/14 5:49 PM, Ethan Furman wrote: [redirecting back to the list] On 10/08/2014 02:23 PM, random...@fastmail.us wrote: On Wed, Oct 8, 2014, at 15:53, Ethan Furman wrote: On 10/08/2014 12:49 PM, random...@fastmail.us wrote: On Wed, Oct 8, 2014, at 15:38, Ethan Furman wrote: LOL, no kidding! The main reason I bother using the operator module is for the readability of not seeing the dunders, and the writability of not having to type them. I'm not sure what situation you would have to type them (as opposed to simply a + b) that the operator module would help with. unittest springs to mind: self.assertRaises(TypeError, op.add, obj1, obj2) Er, my point is, that is not a situation where you would be able to use obj1.__add__ - you'd have to use the operator module *anyway*, and therefore aren't using it just to get the convenience of a non-dunder name. self.assertRaises(TypeError, lambda x, y: x+y, obj1, obj2) Don't forget, in 2.7 you can do: with self.assertRaises(TypeError): obj1 + obj2 -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Toggle
Seymore4Head writes: > I want to toggle between color="Red" and color="Blue" It's good to cultivate ongoing familiarity with the standard library https://docs.python.org/3/library/itertools.html#itertools.cycle> so that you can make use of wheels already invented and maintained:: import itertools colours = ["Red", "Blue"] colour_cycle = itertools.cycle(colours) next(colour_cycle)# → "Red" next(colour_cycle)# → "Blue" next(colour_cycle)# → "Red" next(colour_cycle)# → "Blue" next(colour_cycle)# → "Red" for colour in colour_cycle: # … loops indefinitely # with ‘colour’ bound to each value in turn … -- \ “My roommate got a pet elephant. Then it got lost. It's in the | `\ apartment somewhere.” —Steven Wright | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Toggle
On Thursday, October 9, 2014 7:12:41 AM UTC+5:30, Ben Finney wrote: > Seymore4Head writes: > > I want to toggle between color="Red" and color="Blue" > It's good to cultivate ongoing familiarity with the standard library And language. In recent python3: >>> class Color(Enum): ... Red = 0 ... Blue = 1 ... >>> Color.Red >>> print (Color.Red) Color.Red # Not sure what to make of that distinction... >>> c=Color.Red >>> c = Color.Blue if c==Color.Red else Color.Red >>> c >>> >>> # Better >>> def toggle(c): return Color.Blue if c==Color.Red else Color.Red ... >>> toggle(c) >>> toggle(c) # which means the c has not changed >>> toggle(toggle(c)) [Yeah and like Steven I find the colour of 'color' colourless] -- https://mail.python.org/mailman/listinfo/python-list
Re: Toggle
On 09/10/2014 02:25, Mark Lawrence wrote: On 09/10/2014 01:11, Seymore4Head wrote: I want to toggle between color="Red" and color="Blue" Here is one: if color == "Red": color = "Blue" else: color = "Red" Here is two: if x = "True" color = "Red" else: color="Blue" x= not x Others? Here http://stackoverflow.com/questions/8381735/toggle-a-value-in-python but why couldn't you search in the first place? When I first read this I was extremely jealous of the originator but having used it umpteen times I'm still extremely jealous of the originator!!! Why doesn't my mind work like his? :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Toggle
On Wed, Oct 8, 2014, at 23:02, Mark Lawrence wrote: > When I first read this I was extremely jealous of the originator but > having used it umpteen times I'm still extremely jealous of the > originator!!! Why doesn't my mind work like his? :) You could also keep the ints in two variables and do a ^= b : b ^= a : a ^= b. Or use a, b = b, a. What I don't see in that answer is any benchmarking support for his sweeping assertions of what is the fastest version. -- https://mail.python.org/mailman/listinfo/python-list
Re: Toggle
On Thu, Oct 9, 2014 at 2:54 PM, wrote: > On Wed, Oct 8, 2014, at 23:02, Mark Lawrence wrote: >> When I first read this I was extremely jealous of the originator but >> having used it umpteen times I'm still extremely jealous of the >> originator!!! Why doesn't my mind work like his? :) > > You could also keep the ints in two variables and do a ^= b : b ^= a : a > ^= b. Or use a, b = b, a. What I don't see in that answer is any > benchmarking support for his sweeping assertions of what is the fastest > version. Possibly because it doesn't matter. Who cares how fast it is? All you need to do is go from either of two states to the other. If the performance of that has any impact whatsoever on your code, there's something wrong with your design. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Toggle
On Wed, 08 Oct 2014 19:34:30 -0700, Rustom Mody wrote: Color.Red > print (Color.Red) > Color.Red > > # Not sure what to make of that distinction... That's because the interactive interpreter displays the repr() of objects (except for None, which it suppresses), while print outputs the str() of them. py> class Test: ... def __repr__(self): return "repr" ... def __str__(self): return "str" ... py> x = Test() py> x repr py> print(x) str That's an old, old part of Python, going back to Python 1.5 or older, if I remember correctly. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Toggle
Seymore4Head wrote:
I want to toggle between color="Red" and color="Blue"
toggle = {"Red": "Blue", "Blue": "Red"}
color = toggle[color]
--
https://mail.python.org/mailman/listinfo/python-list
Re: Toggle
On Oct 8, 2014, at 9:57 PM, Gregory Ewing wrote: > Seymore4Head wrote: >> I want to toggle between color="Red" and color="Blue" Don’t forget polymorphic dispatch… class Red(object): def toggle(self): return Blue() class Blue(object): def toggle(self): return Red() Blue().toggle().toggle().toggle().toggle().toggle() :) -- Travis Griggs Objologist "Some of them wanted to sell me snake oil and I'm not necessarily going to dismiss all of these, as I have never found a rusty snake." --Terry Pratchett -- https://mail.python.org/mailman/listinfo/python-list
Re: Toggle
On Thursday, October 9, 2014 10:26:41 AM UTC+5:30, Steven D'Aprano wrote: > On Wed, 08 Oct 2014 19:34:30 -0700, Rustom Mody wrote: > Color.Red > print (Color.Red) > > Color.Red > > # Not sure what to make of that distinction... > That's because the interactive interpreter displays the repr() of objects > (except for None, which it suppresses), while print outputs the str() of > them. Yeah... What I meant to wonder upon was: "Is this behavior what the pro-print or the anti-print folks like?" In any case that the P in REPL is not *exactly* the same as print (or equivalently the distinction between str and repr) makes for some intricate noob confusions. BTW is there some flag that can make them identical? -- https://mail.python.org/mailman/listinfo/python-list
Re: Toggle
On Thu, Oct 9, 2014 at 4:39 PM, Rustom Mody wrote: > On Thursday, October 9, 2014 10:26:41 AM UTC+5:30, Steven D'Aprano wrote: >> On Wed, 08 Oct 2014 19:34:30 -0700, Rustom Mody wrote: > >> Color.Red >> print (Color.Red) >> > Color.Red >> > # Not sure what to make of that distinction... > >> That's because the interactive interpreter displays the repr() of objects >> (except for None, which it suppresses), while print outputs the str() of >> them. > > Yeah... > > What I meant to wonder upon was: "Is this behavior what the pro-print or the > anti-print folks like?" > > In any case that the P in REPL is not *exactly* the same as print > (or equivalently the distinction between str and repr) makes for some > intricate noob confusions. > > BTW is there some flag that can make them identical? I haven't used a proprinter since our XL24E died. Never used an antiprinter, myself. Here's how to make print() output the repr() of something: _ORIG_PRINT = print def print(*args, **kw): return _ORIG_PRINT(*(repr(arg) for arg in args), **kw) But what's the point? (Also: Have fun backporting that to 2.5, it won't be easy.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
ZMQError: Resource temporarily unavailable
I am using zero-mq for IPC between two machines.
My zmq function is given below
def recieve_messages(self):
string = self.sub_socket.recv(flags=zmq.NOBLOCK)
print('flow mod messages recieved {}'.format(string))
When I run the program however I get the following error.
string = self.sub_socket.recv(flags=zmq.NOBLOCK)
File "socket.pyx", line 616, in zmq.core.socket.Socket.recv
(zmq/core/socket.c:5961)
File "socket.pyx", line 650, in zmq.core.socket.Socket.recv
(zmq/core/socket.c:5832)
File "socket.pyx", line 119, in zmq.core.socket._recv_copy
(zmq/core/socket.c:1669)
ZMQError: Resource temporarily unavailable
Can someone explain what is likely causing this error.
--
https://mail.python.org/mailman/listinfo/python-list
trying idle
Been using emacs for over 20 years and teaching python for 10. And getting fed up that my audience looks at me like Rip van Winkle each time I start up emacs... So trying out Idle... Some specific and some general questions: My audience consists of people having linux and windows and macbooks. Does Idle run on all these? [Remember seeing some adventures with Tkinter...] Particularly with macs my knowledge is at the level: "How the ^%*)( do you right click without a right-click button?" So I would like to avoid something that is not quite working. Specific: Is there a way to cut-paste a snippet from the interpreter window containing ">>> " "... " into the file window and auto-remove the prompts? [I have a vague recollection of Terry showing somethin...] -- https://mail.python.org/mailman/listinfo/python-list
