Re: Tuples and immutability
John O'Hagan : > Same object, just a different name - but a different result. I get > why, but still find that odd. The general principle is stated in the language specification: http://docs.python.org/3.2/reference/simple_stmts.html #augmented-assignment-statements>: Also, when possible, the actual operation is performed in-place, meaning that rather than creating a new object and assigning that to the target, the old object is modified instead. [...] with the exception of the possible in-place behavior, the binary operation performed by augmented assignment [x += y] is the same as the normal binary operations [x = x + y]. We should call += "dual-use technology." Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Can global variable be passed into Python function?
Chris Angelico :
> Simple rule of thumb: Never use 'is' with strings or ints. They're
> immutable, their identities should be their values. Playing with 'is'
> will only confuse you, unless you're specifically going for
> introspection and such.
Here's a use case for "is" with strings (or ints):
class Connection:
IDLE = "IDLE"
CONNECTING = "CONNECTING"
CONNECTED = "CONNECTED"
DISCONNECTING = "DISCONNECTING"
DISCONNECTED = "DISCONNECTED"
def __init__(self):
self.state = IDLE
def connect(self, address):
...
self.state = CONNECTING
...
def disconnect(self):
...
if self.state is CONNECTED:
...
The state objects could have been defined like this:
IDLE = object()
CONNECTING = object()
CONNECTED = object()
DISCONNECTING = object()
DISCONNECTED = object()
However, strings have the advantage in troubleshooting:
sys.stderr.write("state = {}\n".format(self.state))
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
On Fri, 28 Feb 2014 16:00:10 +1100, Chris Angelico wrote: > If we had some other tag, like 'd', we could actually construct a > Decimal straight from the source code. Since source code is a string, > it'll be constructed from that string, and it'll never go via float. Now that Python has a fast C implementation of Decimal, I would be happy for Python 4000 to default to decimal floats, and require special syntax for binary floats. Say, 0.1b if you want a binary float, and 0.1 for a decimal. But for now, backwards-compatibility requires that the default floating point type remains binary float. But we could maybe agitate for a 1.234d Decimal literal type. Care to write a PEP? :-) > The question is how far Python wants to bless the Decimal type with > syntax - after all, if Decimal can get a literal notation, why can't > Fraction, and why can't all sorts of other types? And that's a huge can > of worms. I like Fractions, but I don't think they're important enough for the average users to require literal notation. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Can global variable be passed into Python function?
On Fri, Feb 28, 2014 at 4:39 PM, Mark H. Harris wrote: > On Thursday, February 27, 2014 10:43:23 PM UTC-6, Chris Angelico wrote: > >> Simple rule of thumb: Never use 'is' with strings or ints. They're >> immutable, their identities should be their values. Playing with 'is' >> will only confuse you, unless you're specifically going for >> introspection and such. > > Right. The only time I use "is" is when I'm trying to explain to someone > new to python assignment what is happening inside... what Mark Summerfield > calls "python's beautiful heart," in his his recent book, "Programming in > Python 3" ... a great resource, by the way. > 'is' can and should be used with mutables, to distinguish between identical values with different identities. It's also appropriate to use 'is' with special singletons like None. Just be careful of ints and strings. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: posting code snippets
On Fri, Feb 28, 2014 at 9:15 AM, Ben Finney wrote: > Since you'll be posting the code in-line, make sure it's short. Since > it'll be short, make sure it's complete — we should need nothing else to > run the code and expect to see the same behaviour you're seeing. > > Since you'll be making it short, complete, and still demonstrating the > behaviour, you may even get the result that you understand the cause of > the behaviour before posting it. Everyone wins! :-) Which is the scientific basis of the astonishingly successful (that is, it's astonishing to people who don't understand) debugging technique of Rubber Ducking, or talking to your teddy bear, or other variants of the subject. (I have a figurine from American McGee's "Alice: Madness Returns" who is extremely helpful to me. She's pretty, she's smart, and she's pretty smart.) By the time you've explained it to someone, you've boiled the problem down into a manageable form, and that often helps you solve the problem yourself. The problem does have to believe that the rubber duck/teddy bear/figurine is an expert, though. I've had my siblings or parents come to me with problems and, without saying a word or touching the computer or anything, I've solved them. The problem itself respects my skill, and retracts its objection and solves itself. Why this works I am not sure, but just remember to treat your teddy bear as an intelligent partner in the debugging process, not as an idiot who just gets in the way. He's a brilliant programmer from another dimension; he knows all about coding, but not about your code, so you have to explain its little oddities to him. (Or her. Female teddy bears are just as good at debugging as male ones are.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Can global variable be passed into Python function?
On Thursday, February 27, 2014 10:43:23 PM UTC-6, Chris Angelico wrote: > Simple rule of thumb: Never use 'is' with strings or ints. They're > immutable, their identities should be their values. Playing with 'is' > will only confuse you, unless you're specifically going for > introspection and such. Right. The only time I use "is" is when I'm trying to explain to someone new to python assignment what is happening inside... what Mark Summerfield calls "python's beautiful heart," in his his recent book, "Programming in Python 3" ... a great resource, by the way. -- https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
On Fri, Feb 28, 2014 at 4:18 PM, Mark H. Harris wrote: > do I make the assumption that all functions will take a string as argument > and then let interactive users bare the responsibility to enter a string or > decimal... avoiding floats... Just have your users pass in Decimal objects. They can construct them however they wish. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
On Thursday, February 27, 2014 10:26:59 PM UTC-6, Chris Angelico wrote: > Create Decimal values from strings, not from the str() of a float, > which first rounds in binary and then rounds in decimal. > Thanks Chris... another excellent point... ok, you guys have about convinced me (which is spooky) but, hey, I'm teachable... what is the best strategy then? Many of the functions of my dmath.py are algorithms which calculate infinite series to convergence out there at some number of precision ... do I make the assumption that all functions will take a string as argument and then let interactive users bare the responsibility to enter a string or decimal... avoiding floats... or use try and toss and error if the rules are not followed, or what?I do see that I'm trying to solve a problem the wrong way,... just not sure what is the better approach. If you get a chance, take a look at the dmath.py code on: https://code.google.com/p/pythondecimallibrary/ I got the repository working correctly for me, and the files can be viewed on-line ... its a long script, but not that hard to look through because all the functions pretty much work the same... when you've seen one converging series function in python you've seen them all! Thanks again, Chris. -- https://mail.python.org/mailman/listinfo/python-list
Re: Tuples and immutability
On Thu, 27 Feb 2014 18:19:09 +0200 Marko Rauhamaa wrote: > Eric Jacoboni : > > a_tuple[1] += [20] > > Traceback (most recent call last): > > File "", line 1, in > > TypeError: 'tuple' object does not support item assignment > > > > [...] > > > > But, then, why a_tuple is still modified? > > That's because the += operator > > 1. modifies the list object in place > > 2. tries to replace the tuple slot with the list (even though the > list hasn't changed) > > It's Step 2 that raises the exception, but the damage has been done > already. > > One may ask why the += operator modifies the list instead of creating > a new object. That's just how it is with lists. > > BTW, try: > >>>> a_tuple[1].append(20) >>>> a_tuple[1].extend([20]) > > Try also: > >>>> a_tuple[1] = a_tuple[1] > [...] Also try: x = a_tuple[1] #What's in a name? x is a_tuple[1] #Obviously, but: x += [1] #No error a_tuple[1] += [1] #Error Same object, just a different name - but a different result. I get why, but still find that odd. -- John -- https://mail.python.org/mailman/listinfo/python-list
Re: posting code snippets
"Mark H. Harris" Wrote in message: > my isp withdrew the post service (nntp) from their server at end of 2011... > and I didn't notice till now! ha! So, I'm not using seamonkey any > longer... using google groups/ and that has been a fit to get used to, but > I'm making progress. > > You could still use nntp, if you switch to gmane.comp.python. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
On Fri, Feb 28, 2014 at 3:41 PM, Mark H. Harris wrote: > So, I am thinking I need to mods... maybe an idmath.py for interactive > sessions, and then dmath.py for for running within my scientific scripts... > ?? No; the solution is to put quotes around your literals in interactive mode, too. There's no difference between interactive and script mode, and adding magic to interactive mode will only cause confusion. Alternatively, there is another solution that's been posited from time to time: Decimal literals. We currently have three forms of numeric literal, which create three different types of object: >>> type(1) >>> type(.1) >>> type(1j) If we had some other tag, like 'd', we could actually construct a Decimal straight from the source code. Since source code is a string, it'll be constructed from that string, and it'll never go via float. Something like this: >>> type(0.1d) which currently is a SyntaxError, so it wouldn't collide with anything. The question is how far Python wants to bless the Decimal type with syntax - after all, if Decimal can get a literal notation, why can't Fraction, and why can't all sorts of other types? And that's a huge can of worms. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
On Thursday, February 27, 2014 9:15:36 PM UTC-6, Steven D'Aprano wrote:
> Decimal uses base 10, so it is a better fit for numbers we
> write out in base 10 like "0.12345", but otherwise it suffers from the
> same sort of floating point rounding issues as floats do.
>
>
> py> Decimal('1.2345').as_tuple()
> DecimalTuple(sign=0, digits=(1, 2, 3, 4, 5), exponent=-4)
>
> py> Decimal('1234.5').as_tuple()
> DecimalTuple(sign=0, digits=(1, 2, 3, 4, 5), exponent=-1)
>
Steven, thank you, your explanation here is splendid, and has cleared up some
of my confusion about Decimal, and given me a tool besides ('preciate it !) I
did not investigate .as_tuple() nice.
Take a look at this: From IDLE
>>> from decimal import *
>>> s=Decimal(.1)
>>> s.as_tuple()
DecimalTuple(sign=0, digits=(1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
5, 5, 5, 1, 1, 1, 5, 1, 2, 3, 1, 2, 5, 7, 8, 2, 7, 0, 2, 1, 1, 8, 1, 5, 8, 3,
4, 0, 4, 5, 4, 1, 0, 1, 5, 6, 2, 5), exponent=-55)
>>>
>>> s=Decimal('.1')<= .1 as string
>>> s.as_tuple()
DecimalTuple(sign=0, digits=(1,), exponent=-1)
>>>
Big difference, yes?You have hit the nail on the head, because as you say,
it is very unfortunate that the function does not know whether it has been
typed in by hand (a big problem) or whether it comes from an intermediate
calculated result (maybe an even bigger problem. rats().
So, I am thinking I need to mods... maybe an idmath.py for interactive
sessions, and then dmath.py for for running within my scientific scripts... ??
Thanks for your input.
kind regards,
--
https://mail.python.org/mailman/listinfo/python-list
Re: Can global variable be passed into Python function?
On Fri, Feb 28, 2014 at 1:29 PM, Mark H. Harris wrote: > a=1024 > b=a > b=1024 > a is b > False No no no no! They're not pointing to the same integer any more. Now, if you change the "b=1024" from being a mostly-useless assignment (to another int with the same value) into being a comparison, then it'll be safe. But you're assigning "b=a" and then immediately reassigning "b=1024". Simple rule of thumb: Never use 'is' with strings or ints. They're immutable, their identities should be their values. Playing with 'is' will only confuse you, unless you're specifically going for introspection and such. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: end quote help for a newbie
On 27/02/2014 8:41 PM, Chris Angelico wrote:
On Thu, Feb 27, 2014 at 9:30 PM, Peter Clark wrote:
# Dragons and dungeons, based on CP/M program messages from ca. 1966
# This version designed and produced by peter clark beginning in December 2013
def startandload(n):# introduce program and allow messages to be
loaded/amended
x = str(input("Welcome Adventurer, what is your name?"))
if x==('load'):
y = str(input("messages, places or things?"))
if y in("messages", "places","things"):
print("OK")
else: print("Wrong")
if x==('restart'):
y = str(input("game reference"))
if y in("messages", "places","things"):
print("*** to be done - load and restart game ***")
else: print("Wrong")
while True:
startandload
The problem is right at the end: you don't actually call the function.
You always need parentheses to call a function.
`startandload` also takes a parameter that doesn't seem to be used.
I'm also a bit
confused as to your reason for running a function called
"startandload" (which seems to be initialization) in an infinite loop;
you possibly just want to call it once.
Or perhaps:
if __name__ == '__main__':
startandload()
--
https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
On Fri, Feb 28, 2014 at 1:15 PM, Mark H. Harris wrote:
> Its just easier to type D(2.78) than Deciaml('2.78').
It's easier to type 2.78 than 2.718281828, too, but one of them is
just plain wrong. Would you tolerate using 2.78 for e because it's
easier to type? I mean, it's gonna be close.
Create Decimal values from strings, not from the str() of a float,
which first rounds in binary and then rounds in decimal.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Output JSON-schema from bottle application?
Are there libraries for doing this? I would like to autogenerate JSON-schema for use inside an API explorer. However whenever there is a schema change; I would only like to change the schema in one place (where possible). E.g.: For use here - https://github.com/salesking/json-schema-browser How do I do this? Thanks for all suggestions, Alec Taylor -- https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
On Thu, 27 Feb 2014 15:00:45 -0800, Mark H. Harris wrote:
> Decimal does not keep 0.1 as a floating point format (regardless of
> size) which is why banking can use Decimal without having to worry about
> the floating formatting issue... in other words, 0.0 is not stored in
> Decimal as any kind of floating value... its not rounded it really
> is Decimal('0.1').
I'm sorry, but that is incorrect. Decimal is a floating point format,
same as float. Decimal uses base 10, so it is a better fit for numbers we
write out in base 10 like "0.12345", but otherwise it suffers from the
same sort of floating point rounding issues as floats do.
py> a = Decimal("1.1e20")
py> b = Decimal("1.1e-20")
py> assert b != 0
py> a + b == a
True
In the case of 0.1 (I assume your "0.0" above was a typo), it is a
floating point value. You can inspect the fields' values like this:
py> x = Decimal("0.1")
py> x.as_tuple()
DecimalTuple(sign=0, digits=(1,), exponent=-1)
There's a sequence of digits, and an exponent that tells you where the
decimal point goes. That's practically the definition of "floating
point". In Python 3.2 and older, you can even see those fields as non-
public attributes:
py> x._int
'1'
py> x._exp
-1
(In Python 3.3, the C implementation does not allow access to those
attributes from Python.)
This is perhaps a better illustrated with a couple of other examples:
py> Decimal('1.2345').as_tuple()
DecimalTuple(sign=0, digits=(1, 2, 3, 4, 5), exponent=-4)
py> Decimal('1234.5').as_tuple()
DecimalTuple(sign=0, digits=(1, 2, 3, 4, 5), exponent=-1)
[...]
> The reason is that Decimal(.1) stores the erroneous float in the Decimal
> object including the float error for .1and D(.1) works correctly
> because the D(.1) function in my dmath.py first converts the .1 to a
> string value before handing it to Decimal's constructor(s)
That *assumes* that when the user types 0.1 as a float value, they
actually intend it to have the value of 1/10 rather than the exact value
of 3602879701896397/36028797018963968. That's probably a safe bet, with a
number like 0.1, typed as a literal.
But how about this number?
py> x = 3832879701896397/36028797218963967
py> Decimal(x)
Decimal('0.10638378180104603176747701809290447272360324859619140625')
py> Decimal(str(x))
Decimal('0.10638378180104603')
Are you *absolutely* sure that the user intended x to have the second
value rather than the first? How do you know?
In other words, what you are doing is automatically truncating calculated
floats at whatever string display format Python happens to use,
regardless of the actual precision of the calculation. That happens to
work okay with some values that the user types in by hand, like 0.1. But
it is a disaster for *calculated* values.
Unfortunately, there is no way for your D function to say "only call str
on the argument if it is a floating point literal typed by the user".
But what you can do is follow the lead of the decimal module, and leave
the decision up to the user. The only safe way to avoid *guessing* what
value the caller wanted is to leave the choice of truncating floats up to
them. That's what the decimal module does, and it is the right decision.
If the user passes a float directly, they should get *exact conversion*,
because you have no way of knowing whether they actually wanted the float
to be truncated or not. If they do want to truncate, they can pass it to
string themselves, or supply a string literal.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
References, and avoiding use of “variable” (was: Can global variable be passed into Python function?)
"Mark H. Harris" writes: > So, yeah, thinking about variables is just not going away. Right. I would like, ideally, for the Python documentation to avoid mentioning that term entirely; and I would hope for that to promote a better understanding of Python's data model. The wider programming community, though, will no doubt continue to use that term to refer to various (incompatible) data models, and I certainly don't expect the Python community to pretend it doesn't exist. I encourage getting rid of it from Python documentation, but not getting rid of it from discussion in the community. > I finally decided (in my own head) that I would completely give up on > the 'variable' concept (intellectually) and help folks try to > understand references and reference counting. Reference counting isn't a concept one needs to present to newcomers, IMO. It is sufficient to explain that the Python runtime is free to discard an object when nothing refers to it any more. There's no need to explain to a newcomer the garbage-collection implementation details, precisely *because* it's an implementation detail. Some Python implementations use reference counting, some don't, and each implementation is free to do what it likes so long as the data model guarantees are preserved. The user normally shouldn't care, because they shouldn't have to depend on any specific garbage-collection behaviour. So: it's good to present the concept of “references”, and use “name binding” instead of “variable”; but there's no need to present “reference counting”, which is a Python-implementation-detail technical concept that IMO doesn't need to be in the newcomer's head. -- \ “The trouble with the rat race is that even if you win, you're | `\ still a rat.” —Jane Wagner, via Lily Tomlin | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Can global variable be passed into Python function?
On Thursday, February 27, 2014 8:07:20 PM UTC-6, Steven D'Aprano wrote: > If they point to the same piece of memory -- which, by the way, can be > moved around if the garbage collector supports it -- then A is B cannot > possibly return False. > hi Steve, long time, yes, my whole point exactly. And we all know what python is doing under the covers for small ints like 0 - 256 ... in which case consider the following: a=128 b=a b=128 a is b True But.. consider this a=1024 b=a b=1024 a is b False For small ints below a certain value (257) A is B will always be True but now for ints above that value, as I've shown, A=257 B=A B=257 A is B False But for the variable discussion (like in BASIC, or even C) A=128, B=A, A and B are two pieces of memory that both happen to be variables containing different pieces of memory. For python, the references to small ints (as above) will almost always point to the same int object for each reference; hence the need for reference counts. Folks that think of assignment in python with a BASIC, or even C, mentality will have trouble understanding the difference between "==" and "is" and why... and they won't get reference counting. Cheers -- https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
On Thursday, February 27, 2014 5:50:55 PM UTC-6, Oscar Benjamin wrote:
> . . . Calling Decimal on a float performs an exact binary to
> decimal conversion. Your reasoning essentially assumes that every
> float should be interpreted as an approximate representation for a
> nearby decimal value.
That is the whole point exactly. Yes, the exact binary to decimal conversion
for float is the problem precisely. But my solution does not assume any such
thing... because the decimal module is "advertised" to support what I'm doing.
In other words, decimal correctly builds from a string literal in any case;
even intermediary values. Well, the digits past 16 (for a double) aren't valid
anyway... and the ones before that (when passed to decimal as a string) get
correctly created as a decimal object.
But here is the other point... I am not planning on passing *any* of these
functions a float... my system that uses dmath uses strings only, or decimals.
str(Decimal) works, as does Decimal(str()). So, I'm not really
interested in floats at all... but, and here's the big BUT, I'm expecting
folks to use dmath.py from the console (as I plan to) and they are going to
punch in *floats*. why? because its natural.
Its just easier to type D(2.78) than Deciaml('2.78').
Neither here nor there but the frustration is the fact that floats are
so 1982. Know what I mean? This is the 21st century, and you know what, we
have got to get past this:
>>>
>>> Decimal(.1)
Decimal('0.155511151231257827021181583404541015625')
>>>
In other words, we need to move to a numeric system of computation (decimal is
a good start) that does not keep track of real values as IEEE floats. Back in
the day, that was ok... today, its unacceptable.
So, Krah has a really nice (and fast) module that will help at least the python
community (and users) to move into the 21st century. My hat is off to Stefan,
that's for sure.
I am going to keep playing with this, and making the changes you have
suggested... I'll put the code back up there on code.google and see if I can
make the repository work like its supposed to..
Thanks again for your assistance, I really appreciate it, Oscar.
--
https://mail.python.org/mailman/listinfo/python-list
RE: Descriptor type hinting
> Surely the answer will depend on the linter you are using. Care to tell > us, or shall we guess? Hey Steven, I am using PyCharm, I have to admit I feel silly on this one. I had a buried assignment that overrode the inferred type. It wasn't until a fresh set of eyes confirmed something was awry and we looked... Add one to the fail list for me. Thanks for taking the time to respond, jlc -- https://mail.python.org/mailman/listinfo/python-list
Re: Can global variable be passed into Python function?
On Thu, 27 Feb 2014 15:29:01 -0800, Mark H. Harris wrote: > Knowing that A points to an int, and > that B=A, now B points to the VERY SAME int... they are references > pointing to the same piece of memory. And of course we want new folks to > understand the issue of: A==B > True > A is B > False > . and WHY that is or isn't If they point to the same piece of memory -- which, by the way, can be moved around if the garbage collector supports it -- then A is B cannot possibly return False. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Descriptor type hinting
On Thu, 27 Feb 2014 22:21:31 +, Joseph L. Casale wrote: > How does one satisfy a lint/type checker with the return value of a > class method decorated with a descriptor? Surely the answer will depend on the linter you are using. Care to tell us, or shall we guess? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: exec and locals
On Fri, 28 Feb 2014 00:29:35 +1300, Gregory Ewing wrote: > Steven D'Aprano wrote: >> On Thu, 27 Feb 2014 16:34:33 +1300, Gregory Ewing wrote: >> >>>Why not just use this version all the time? It should work in both 2.x >>>and 3.x. >> >> Because that's yucky. It's an aesthetic thing: when supported, I want >> the Python interpreter to manage the context manager. > > More yucky than wrapping the Py3 version in an exec? To my way of > thinking, that cancels out any elegance that might have been gained from > using a with-statement. > > Do you really need to use the context manager at all? Could you just > write the try-statement that you would have written in Py2 if you didn't > have a context manager? I don't *have* to do it any particular way, but the way it works now, the version of the inner function (which does eventually get exposed to the caller) is simple with statement wrapping a function call. So for seven of the eight versions of Python supported (2.5 through 3.4) the function is the simplest it can be. Even if the code creating that function is a tiny bit more complex, since it is wrapped inside an exec. For the other two versions (2.4 and 2.5), I have to fall back on a more complex chunk of code. (And yes, it's deliberate that 2.5 gets counted in both groups.) I'm not saying that I have objective reasons for preferring this way over the manual alternative, or at least not *strong* objective reasons. It's mostly subjective. I don't expect to convince you my way is better, and I doubt that you'll convince me your way is better. But if I were to try, I'd put it this way: At a cost of six (by memory) extra lines of code, including one call to exec, I have an inner function which is *guaranteed* to use the exact same semantics and efficiency of a with-statement when possible, because it *is* a with-statement. Any differences between with-statement and my manual handling will only affect 2.4 and sometimes 2.5, rather than everything. The only differences that I know of are insignificant -- the byte-code will be different, there may be trivial performance differences -- but if it turns out to be some meaningful difference, I have three choices: 1) deny that the difference is meaningful; 2) accept that the difference is meaningful, and fix it; or 3) accept that the difference is meaningful, but say that it won't be fixed for 2.4 and 2.5. If I use the same manual handling for all versions, then I don't have that last option, no matter how unlikely it is that I will need it. But really, it's a subjective choice of what feels right to me in this instance. If the body of the with-statement was bigger, or if the feature in question was something else, I might choose a different approach. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Extracting parts of string between anchor points
On Fri, 28 Feb 2014 00:55:01 +, Denis McMahon wrote: > The code in the file at the url below processes 17 different cases. It > may help, or it may confuse. > http://www.sined.co.uk/tmp/strparse.py.txt I added some more cases to it, and then realised that the code could actually be simplified quite a lot. So now it has been. -- Denis McMahon, denismfmcma...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Extracting parts of string between anchor points
On Thu, 27 Feb 2014 20:07:56 +, Jignesh Sutar wrote: > I've kind of got this working but my code is very ugly. I'm sure it's > regular expression I need to achieve this more but not very familiar > with use regex, particularly retaining part of the string that is being > searched/matched for. > > Notes and code below to demonstrate what I am trying to achieve. Any > help, > much appreciated. It seems you have a string which may be split into between 1 and 3 substrings by the presence of up to 2 delimeters, and that if both delimeters are present, they are in a specified order. You have several possible cases which, broadly speaking, break down into 4 groups: (a) no delimiters present (b) delimiter 1 present (c) delimiter 2 present (d) both delimiters present It is important when coding for such scenarios to consider the possible cases that are not specified, as well as the ones that are. For example, consider the string: "" where you have both delims, in sequence, but no other data elements. I believe there are at least 17 possible combinations, and maybe another 8 if you allow for the delims being out of sequence. The code in the file at the url below processes 17 different cases. It may help, or it may confuse. http://www.sined.co.uk/tmp/strparse.py.txt -- Denis McMahon, denismfmcma...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
On 27 February 2014 23:00, Mark H. Harris wrote:
> On Thursday, February 27, 2014 10:24:23 AM UTC-6, Oscar Benjamin wrote:
>
> from decimal import Decimal as D
>> >>> D(0.1)
>> Decimal('0.155511151231257827021181583404541015625')
>
> hi Oscar, well, that's not what I'm doing with my D()... I'm not just
> making D() mimic Decimal... look inside it... there's a str() call
> consider the following experiment and you'll see what I'm talking about...
I understood what your code is doing but I'm not sure if you do.
Calling str on a float performs an inexact binary to decimal
conversion. Calling Decimal on a float performs an exact binary to
decimal conversion. Your reasoning essentially assumes that every
float should be interpreted as an approximate representation for a
nearby decimal value. This is probably true if the user wrote "a =
0.1" but is generally not true in the kind of numeric code that is
likely to be using the transcendental functions defined in your dmath
module.
Calling Decimal(str(float)) introduces entirely avoidable inaccuracy
in your code when the primary purpose of your code as accuracy!
Oscar
--
https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
On Friday, February 28, 2014 12:00:45 AM UTC+1, Mark H. Harris wrote:
> On Thursday, February 27, 2014 10:24:23 AM UTC-6, Oscar Benjamin wrote:
> from decimal import Decimal as D
>
> > >>> D(0.1)
>
> > Decimal('0.155511151231257827021181583404541015625')
>
> >
> hi Oscar, well, that's not what I'm doing with my D()... I'm not just
> making D() mimic Decimal... look inside it... there's a str() call
> consider the following experiment and you'll see what I'm talking about...
> >>> from dmath import *
> >>> pi = D(piagm(32))
> >>> pi
> Decimal('3.14159265358979323846264338327950')
> >>> pi * Decimal(.1)
> Decimal('0.31415926535897934128560682837111')
> >>>
> >>> pi * D(.1)
> Decimal('0.31415926535897932384626433832795')
> >>>
> >>>
> You will notice that Decimal(.1) and my D(.1) work against PI
> differently... in fact, Decimal(.1) decimates PI
> The reason is that Decimal(.1) stores the erroneous float in the Decimal
> object including the float error for .1and D(.1) works correctly
> because the D(.1) function in my dmath.py first converts the .1 to a string
> value before handing it to Decimal's constructor(s)
What Oscar tried to make clear is that Decimal(.1) does not store an
"erroneous" float in the Decimal object, but an "honest" one.
Maybe this becomes clearer with calculations instead of literal values:
>>> 155511151231257827021181583404541015625/10**55
0.1
now try:
D(155511151231257827021181583404541015625/10**55)
vs
Decimal(155511151231257827021181583404541015625/10**55)
for an example that it is not better, in general, to go through the
str()-mediated rounding you are doing.
Of course, if the user *intended* that float(.1) to mean exactly 0.1 then your
D class does a good job at guessing, but only then.
The Decimal class, on the other hand, leaves the choice to the user as you are
illustrating perfectly in your own example below:
> Now, try this experiment:again from IDLE and dmath.py
>
> >>> from dmath import *
> >>> pi = D(piagm(32))
> >>> pi
> Decimal('3.14159265358979323846264338327950')
> >>>
> >>> pi * Decimal(str(.1))
> Decimal('0.31415926535897932384626433832795')
> >>>
> >>> pi * D(.1)
> Decimal('0.31415926535897932384626433832795')
see? Decimal(.1) gives the exact representation of the float, but Decimal('.1')
is the way to get your D()'s default behavior.
> You see? All of my functions make certain that when the Decimal objects are
> created that the string constructor gets called so that, in this case,
> .1 really is 0.1 precisely, not floating format.
Yes, just that this is almost never what your users will want to happen ...
The Decimal constructor is really well designed, so stick to it !
Best,
Wolfgang
--
https://mail.python.org/mailman/listinfo/python-list
Re: Can global variable be passed into Python function?
On Thursday, February 27, 2014 11:54:44 AM UTC-6, Ned Batchelder wrote: > Mark, thanks for helping to answer the OP's question. We've covered (in > depth) in the rest of this thread, that Python *does* have the concept > of a variable, it just behaves differently than some other popular > programming languages (but exactly the same as some other popular > programming languages!) > I do not disagree. I've had the same discussion over the years since using python, and often its a rope soaking contest... some folks get so enamored with the 'way' it works under the covers that they forget how people think about it as they are trying (as normal people) to use the language (instead of BASIC). So, yeah, thinking about variables is just not going away. I finally decided (in my own head) that I would completely give up on the 'variable' concept (intellectually) and help folks try to understand references and reference counting. Knowing that A points to an int, and that B=A, now B points to the VERY SAME int... they are references pointing to the same piece of memory. And of course we want new folks to understand the issue of: A==B True A is B False . and WHY that is or isn't :) it just helps to get the 'variable' idea out of here... it really is something completely different in python. Thanks for the note, kind regards, marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: posting code snippets
On Thursday, February 27, 2014 4:15:16 PM UTC-6, Ben Finney wrote: > > Post your code in-line with your message. This is for the sake of the > people whose time you're requesting, and of later readers who will find > the thread when searching the archives -- URLs to snippets are likely to > be invalid later. > Thanks everyone for the great responses will do. I read this group frequently, but have not posted for quite some time for time and focus reasons. To tell you just how long, well, my isp withdrew the post service (nntp) from their server at end of 2011... and I didn't notice till now! ha! So, I'm not using seamonkey any longer... using google groups/ and that has been a fit to get used to, but I'm making progress. :-} Thanks again -- https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
On Thursday, February 27, 2014 10:24:23 AM UTC-6, Oscar Benjamin wrote:
from decimal import Decimal as D
> >>> D(0.1)
> Decimal('0.155511151231257827021181583404541015625')
>
hi Oscar, well, that's not what I'm doing with my D()... I'm not just
making D() mimic Decimal... look inside it... there's a str() call
consider the following experiment and you'll see what I'm talking about...
Decimal does not keep 0.1 as a floating point format (regardless of size)
which is why banking can use Decimal without having to worry about the floating
formatting issue... in other words, 0.0 is not stored in Decimal as any kind
of floating value... its not rounded it really is Decimal('0.1').
Ok, so for the experiment: consider this exchange from IDLE:
>>> RESTART ==
>>> from dmath import *
>>> pi = D(piagm(32))
>>> pi
Decimal('3.14159265358979323846264338327950')
>>> pi * Decimal(.1)
Decimal('0.31415926535897934128560682837111')
>>>
>>> pi * D(.1)
Decimal('0.31415926535897932384626433832795')
>>>
>>>
You will notice that Decimal(.1) and my D(.1) work against PI
differently... in fact, Decimal(.1) decimates PI
The reason is that Decimal(.1) stores the erroneous float in the Decimal object
including the float error for .1and D(.1) works correctly because the
D(.1) function in my dmath.py first converts the .1 to a string value before
handing it to Decimal's constructor(s)
Now, try this experiment:again from IDLE and dmath.py
>>> = RESTART =
>>> from dmath import *
>>> pi = D(piagm(32))
>>> pi
Decimal('3.14159265358979323846264338327950')
>>>
>>> pi * Decimal(str(.1))
Decimal('0.31415926535897932384626433832795')
>>>
>>> pi * D(.1)
Decimal('0.31415926535897932384626433832795')
>>>
You see? All of my functions make certain that when the Decimal objects are
created that the string constructor gets called so that, in this case,
.1 really is 0.1 precisely, not floating format.
and take a look at this:
>>> RESTART ==
>>> from dmath import *
>>> D(.1)
Decimal('0.1')
>>>
With my dmath D() function the object holds 0.1 precisely... its not the
float 0.1 rounded ...
shifting gears a bit
The real reason I pushed a commit of a gzip tarball to code.google is because
I've never used code.google before (thought I'd give it a try) and I didn't
realize that its only pull / download is a ZIP... so I am going to take your
advice and remove the tarballs and just put the code up there... if I can get
my GIT to work ... its GIVing me fits (probably because I don't have it
configured right on this system.
Thanks for the discussion... its helping me get this stuff into my brain, and
its giving me a chance to discuss what's at issue between floats and Decimal.
kind regards,
marcus
--
https://mail.python.org/mailman/listinfo/python-list
Re: Functions help
On Tue, 25 Feb 2014 02:18:43 -, Dennis Lee Bieber wrote: On Mon, 24 Feb 2014 01:01:15 -, "Rhodri James" declaimed the following: The function "range" returns the sequence of numbers 1, 2, 3, 4 and 5 [*], so this has the same effect as if you had typed: Wrong -- it returns the sequence 0, 1, 2, 3, 4... Duh, yes. I do know better than that... -- Rhodri James *-* Wildebeest Herder to the Masses -- https://mail.python.org/mailman/listinfo/python-list
Descriptor type hinting
How does one satisfy a lint/type checker with the return value of a class method decorated with a descriptor? It returns a dict, and I want the type hinting to suggest this versus the str|unknown its defaults to. Thanks, jlc -- https://mail.python.org/mailman/listinfo/python-list
Re: Tuples and immutability
On Thu, Feb 27, 2014 at 2:47 PM, Nick Timkovich wrote: > On Thu, Feb 27, 2014 at 10:33 AM, Chris Angelico wrote: >> >> On Fri, Feb 28, 2014 at 3:27 AM, Eric Jacoboni >> wrote: >> > But, imho, it's far from being a intuitive result, to say the least. >> >> It's unintuitive, but it's a consequence of the way += is defined. If >> you don't want assignment, don't use assignment :) >> >> ChrisA > > > Where is `.__iadd__()` called outside of `list += X`? If the only > difference from `.extend()` is that it returns `self`, but the list was > already modified anyway, why bother with reassignment? x += y is meant to be equivalent, except possibly in-place and more efficient, than x = x + y. If you skip the assignment, and that assignment is meaningful to whatever the left side may be (e.g. assigning to a descriptor or something that invokes __setitem__ or __setattr__), then the operation is not equivalent. -- https://mail.python.org/mailman/listinfo/python-list
Re: posting code snippets
"Mark H. Harris" writes: >Its been too long... can't remember... are there rules here about >posting code snippets, or length considerations, and so forth? Post your code in-line with your message. This is for the sake of the people whose time you're requesting, and of later readers who will find the thread when searching the archives — URLs to snippets are likely to be invalid later. Since you'll be posting the code in-line, make sure it's short. Since it'll be short, make sure it's complete — we should need nothing else to run the code and expect to see the same behaviour you're seeing. Since you'll be making it short, complete, and still demonstrating the behaviour, you may even get the result that you understand the cause of the behaviour before posting it. Everyone wins! :-) For these and other reasons, ensure the example you're showing us is a Simple, Self-Contained, Complete Example http://www.sscce.org/> which demonstrates the issue you're asking about. >A related question, is there a python repository for uploading py >files, patches, suggestions, etc? The place to contribute patches and suggestions is to the project that maintains whatever it is your patch or suggestion is for. What code project are you wanting to contribute to? Look to the home page of that project, and see what resources it has for “Developers” etc. -- https://mail.python.org/mailman/listinfo/python-list
Re: Extracting parts of string between anchor points
On 2014-02-27 15:45, Tim Chase wrote:
> >>> r = re.compile(r"^([^:]*)(?::((?:(?!-:-).)*)(?:-:-(.*))?)?")
If you want to compare both the re method and the string method,
here's a test-harness to play with:
import re
examples = [
("", (None, None, None)),
("Test1A", ("Test1A", None, None)),
("Test2A: Test2B", ("Test2A", "Test2B", None)),
("Test3A: Test3B -:- Test3C", ("Test3A", "Test3B", "Test3C")),
("Test4A -:- Test4B", None),
("Test5A : Test5B : Test5C -:- Test5D", None),
("Test6A : Test6B -:- Test6C -:- Test6D", None),
]
splitter_re = re.compile(r"^([^:]*)(?::((?:(?!-:-).)*)(?:-:-(.*))?)?")
def clean(t):
return [
s.strip() if s else None
for s in t
]
def splitter1(s):
"using regexp"
m = splitter_re.match(s)
if m:
return tuple(clean(m.groups()))
else:
return (None, None, None)
def splitter2(s):
"using string methods"
out1 = out2 = out3 = None
if ":" in s:
if "-:-" in s:
left, _, out3 = clean(s.partition("-:-"))
if ":" in left:
out1, _, out2 = clean(left.partition(":"))
else:
out1 = left
else:
out1, _, out2 = clean(s.partition(":"))
else:
if s:
out1 = s
return (out1, out2, out3)
for method in (splitter1, splitter2):
print("")
print(method.__doc__)
print("=" * len(method.__doc__))
for s, expected in examples:
result = method(s)
if expected is not None:
if result != expected:
print("FAIL: %r got %r, not %r" % (s, result, expected))
else:
print("PASS: %r got %r" % (s, result))
else:
print("UNKN: %r got %r" % (s, result))
Note the differences in Test4.
-tkc
--
https://mail.python.org/mailman/listinfo/python-list
Re: Deepcopying a byte string is quicker than copying it - problem?
On 2/27/2014 4:02 AM, Frank Millman wrote: However, deepcopying a byte string is orders of magnitude quicker than copying it. Actually, looking closer, it is the 'copy' that is slow, not the 'deepcopy' that is quick.. I have created an issue on the bug tracker - http://bugs.python.org/issue20791 Fixed, 12 hours later. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Tuples and immutability
On Fri, Feb 28, 2014 at 8:47 AM, Nick Timkovich wrote: > On Thu, Feb 27, 2014 at 10:33 AM, Chris Angelico wrote: >> >> On Fri, Feb 28, 2014 at 3:27 AM, Eric Jacoboni >> wrote: >> > But, imho, it's far from being a intuitive result, to say the least. >> >> It's unintuitive, but it's a consequence of the way += is defined. If >> you don't want assignment, don't use assignment :) >> >> ChrisA > > > Where is `.__iadd__()` called outside of `list += X`? If the only > difference from `.extend()` is that it returns `self`, but the list was > already modified anyway, why bother with reassignment? Not everything handles += that way. You can't mutate the integer 5 into 7 because someone had 5 in x and wrote "x += 2". So it has to reassign. Actually, integers just don't define __iadd__, but the principle applies. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Python VM university project
Hello! I hope this is the right place to ask about this, sorry if it's inappropriate. At our University we have to do a project for a class called Virtual Execution Environments. We decided that it would be great to work with/on the Python VM. The project has to revolve around one of the following topics: Analysis of Internal Mechanisms, Implementation, Relevant Evaluation, Advanced Usage in a Specific Scenario, Extension. Does anybody have an idea for such a project, that would be interesting/beneficial to explore? We have a group of 3 master's students and the project is for a single semester. Best regards, Daniel Bali -- https://mail.python.org/mailman/listinfo/python-list
Re: Tuples and immutability
On Thu, Feb 27, 2014 at 10:33 AM, Chris Angelico wrote: > On Fri, Feb 28, 2014 at 3:27 AM, Eric Jacoboni > wrote: > > But, imho, it's far from being a intuitive result, to say the least. > > It's unintuitive, but it's a consequence of the way += is defined. If > you don't want assignment, don't use assignment :) > > ChrisA > Where is `.__iadd__()` called outside of `list += X`? If the only difference from `.extend()` is that it returns `self`, but the list was already modified anyway, why bother with reassignment? -- https://mail.python.org/mailman/listinfo/python-list
Re: Extracting parts of string between anchor points
On 2014-02-27 20:07, Jignesh Sutar wrote:
> I've kind of got this working but my code is very ugly. I'm sure
> it's regular expression I need to achieve this more but not very
> familiar with use regex, particularly retaining part of the string
> that is being searched/matched for.
While I suppose this could be done with regular expressions, in this
case it seems like a bit of overkill. Just to show that it can be
done, I give you this monstrosity:
>>> examples = ["Test1A",
... "Test2A: Test2B",
... "Test3A: Test3B -:- Test3C",
... ""]
>>> import re
>>> r = re.compile(r"^([^:]*)(?::((?:(?!-:-).)*)(?:-:-(.*))?)?")
>>> [r.match(s).groups() for s in examples]
[('Test1A', None, None), ('Test2A', ' Test2B', None), ('Test3A', '
Test3B ', ' Test3C'), ('', None, None)]
You'd still have to strip those values that are strings, but that
gets you the core of what you're seeking.
You do omit several edge cases:
to_test = [
"Test4A -:- Test4D",# no ":"
"Test4A : Test4B : Test4C -:- Test4D", # 2x ":"
"Test4A : Test4B -:- Test4C -:- Test4D", # 2x "-:-"
]
what should Out2 and Out3 be in those particular instances?
> Notes and code below to demonstrate what I am trying to achieve.
> Any help, much appreciated.
>
> Examples=["Test1A",
> "Test2A: Test2B",
>"Test3A: Test3B -:- Test3C", ""]
>
> # Out1 is just itself unless if it is empty
> # Out2 is everything left of ":" (including ":" i.e. part A) and
> right of "-:-" (excluding "-:-" i.e. part C)
> # If text doesn't contain "-:-" then return text itself as it is
> # Out3 is everything right of "-:-" (excluding "-:-" i.e. part C)
># If text doesn't contain "-:-" but does contains ":" then
> return part B only
># If it doesn't contain ":" then return itself (unless if it
> empty then "None")
I believe you want something like
examples = [
("", (None, None, None)),
("Test1A", ("Test1A", None, None)),
("Test2A: Test2B", ("Test2A", "Test2B", None)),
("Test3A: Test3B -:- Test3C", ("Test3A", "Test3B", "Test3C")),
# three test-cases with no provided expectations
("Test4A -:- Test4B", None),
("Test5A : Test5B : Test5C -:- Test5D", None),
("Test6A : Test6B -:- Test6C -:- Test6D", None),
]
def clean(t):
return [
s.strip() if s is not None else s
for s in t
]
for s, expected in examples:
out1 = out2 = out3 = None
if ":" in s:
if "-:-" in s:
left, _, out3 = clean(s.partition("-:-"))
if ":" in left:
out1, _, out2 = clean(left.partition(":"))
else:
out1 = left
else:
out1, _, out2 = clean(s.partition(":"))
else:
if s:
out1 = s
result = (out1, out2, out3)
if expected is not None:
if result != expected:
print("FAIL: %r got %r, not %r" % (s, result, expected))
else:
print("PASS: %r got %r" % (s, result))
else:
print("UNKN: %r got %r" % (s, result))
which gives me
PASS: '' got (None, None, None)
PASS: 'Test1A' got ('Test1A', None, None)
PASS: 'Test2A: Test2B' got ('Test2A', 'Test2B', None)
PASS: 'Test3A: Test3B -:- Test3C' got ('Test3A', 'Test3B', 'Test3C')
UNKN: 'Test4A -:- Test4B' got ('Test4A', None, 'Test4B')
UNKN: 'Test5A : Test5B : Test5C -:- Test5D' got ('Test5A', 'Test5B : Test5C',
'Test5D')
UNKN: 'Test6A : Test6B -:- Test6C -:- Test6D' got ('Test6A', 'Test6B', 'Test6C
-:- Test6D')
I find that a good bit more readable than the atrocity of that
regular expression.
-tkc
--
https://mail.python.org/mailman/listinfo/python-list
Re: Extracting parts of string between anchor points
On 27Feb2014 20:07, Jignesh Sutar wrote:
> I've kind of got this working but my code is very ugly. I'm sure it's
> regular expression I need to achieve this more but not very familiar with
> use regex, particularly retaining part of the string that is being
> searched/matched for.
Regexps are quite useful for very variable text. You're just splitting
on ':' and '-:-', which is very easy and does not need a regexp.
Avoid regexps if the code can be written easily and readably without
them; they are cryptic and fragile.
> Notes and code below to demonstrate what I am trying to achieve. Any help,
> much appreciated.
>
> Examples=["Test1A",
> "Test2A: Test2B",
>"Test3A: Test3B -:- Test3C", ""]
Minor remark. Class names tend to have leading uppercase names,
like Foo. ordinary variables tend to have lower case names, like
foo. A habit to get into - it maes your code more readable for
everyone else.
Code suggestions below the code...
> # Out1 is just itself unless if it is empty
> # Out2 is everything left of ":" (including ":" i.e. part A) and right of
> "-:-" (excluding "-:-" i.e. part C)
> # If text doesn't contain "-:-" then return text itself as it is
> # Out3 is everything right of "-:-" (excluding "-:-" i.e. part C)
># If text doesn't contain "-:-" but does contains ":" then return part B
> only
># If it doesn't contain ":" then return itself (unless if it empty then
> "None")
>
> for i,s in enumerate(Examples,start=1):
> Out1=s if len(s)>0 else "Empty"
> Out2=s[:s.find(":")+3] + s[s.find("-:-")+5:] if s.find("-:-")>0 else
> s.strip() if len(s) else "Empty"
> Out3=s[s.find("-:-")+4:] if s.find("-:-")>0 else
> s[s.find(":")+1:].strip() if s.find(":")>0 and len(s)!=s.find(":")+1 else s
> if len(s) else "Empty"
> print "Item%(i)s <%(s)s> Out1 = %(Out1)s" % locals()
> print "Item%(i)s <%(s)s> Out2 = %(Out2)s" % locals()
> print "Item%(i)s <%(s)s> Out3 = %(Out3)s" % locals()
I would be parsing the string using "split", progressively.
Example (completely untested):
# initialise all parts because we will only set the parts
# below if they appear in the text
out1, out2, out3 = '', '', ''
words = s.split(':', 1)
if words: # arrays are false if empty, true if non-empty
out1 = words.pop(0)
# there is a second part - split it on "-:-"
if words:
words = words[0].split('-:-', 1)
out2 = words.pop(0)
if words:
out3 = words.pop(0)
# personally I would leave out1 etc as empty strings and only _print_ the
word "Empty"
# but if you really want to mangle the variables themselves:
if not out1:
out1 = "Empty"
if not out2:
out2 = "Empty"
if not out3:
out3 = "Empty"
Notice that by using split we do not need to do any funny string
index arithmetic.
Cheers,
--
Cameron Simpson
You can't have everything... where would you put it?
- Charles Robinson, cr0...@medtronic.com
--
https://mail.python.org/mailman/listinfo/python-list
Extracting parts of string between anchor points
I've kind of got this working but my code is very ugly. I'm sure it's
regular expression I need to achieve this more but not very familiar with
use regex, particularly retaining part of the string that is being
searched/matched for.
Notes and code below to demonstrate what I am trying to achieve. Any help,
much appreciated.
Examples=["Test1A",
"Test2A: Test2B",
"Test3A: Test3B -:- Test3C", ""]
# Out1 is just itself unless if it is empty
# Out2 is everything left of ":" (including ":" i.e. part A) and right of
"-:-" (excluding "-:-" i.e. part C)
# If text doesn't contain "-:-" then return text itself as it is
# Out3 is everything right of "-:-" (excluding "-:-" i.e. part C)
# If text doesn't contain "-:-" but does contains ":" then return part B
only
# If it doesn't contain ":" then return itself (unless if it empty then
"None")
for i,s in enumerate(Examples,start=1):
Out1=s if len(s)>0 else "Empty"
Out2=s[:s.find(":")+3] + s[s.find("-:-")+5:] if s.find("-:-")>0 else
s.strip() if len(s) else "Empty"
Out3=s[s.find("-:-")+4:] if s.find("-:-")>0 else
s[s.find(":")+1:].strip() if s.find(":")>0 and len(s)!=s.find(":")+1 else s
if len(s) else "Empty"
print "Item%(i)s <%(s)s> Out1 = %(Out1)s" % locals()
print "Item%(i)s <%(s)s> Out2 = %(Out2)s" % locals()
print "Item%(i)s <%(s)s> Out3 = %(Out3)s" % locals()
Output:
Item1 Out1 = Test1A
Item1 Out2 = Test1A
Item1 Out3 = Test1A
Item2 Out1 = Test2A: Test2B
Item2 Out2 = Test2A: Test2B
Item2 Out3 = Test2B #INCORRECT - Should be "Test2A:
Test2B"
Item3 Out1 = Test3A: Test3B -:- Test3C
Item3 Out2 = Test3A: Test3C
Item3 Out3 = Test3C
Item4 <> Out1 = Empty
Item4 <> Out2 = Empty
Item4 <> Out3 = Empty
--
https://mail.python.org/mailman/listinfo/python-list
Re:How to run multiple virtualenv in product server
YE SHANG Wrote in message: > I'm starting to learn virtualenv, I wonder how run python project developed > in virtualenv. > > Here is my situation, there is a server we can access with a common user name > and password, there are many py scripts wrote by different people on this > server. > > If I develop my python project with virtualenv, could I run it in product > server?? > There are many kinds of servers, so we can only guess. Assuming you're logging in with ssh, it would depend on your permissions on your particular account. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: Can global variable be passed into Python function?
On 2/27/14 8:24 AM, Mark H. Harris wrote: As others have noted, python does not have a 'variable' concept (references to objects instead) and so your question is a little ambiguous. Mark, thanks for helping to answer the OP's question. We've covered (in depth) in the rest of this thread, that Python *does* have the concept of a variable, it just behaves differently than some other popular programming languages (but exactly the same as some other popular programming languages!) -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
On Fri, Feb 28, 2014 at 4:07 AM, Terry Reedy wrote: > On 2/27/2014 7:07 AM, Mark H. Harris wrote: > >> Oh, and one more thing... whoever is doing the work on IDLE these >> days, nice job! It is stable, reliable, and just works/ >> appreciate it! > > > As one of 'them', thank you for the feedback. There are still some bugs, but > I hit them seldom enough that I am now looking at enhancement issues. Aside from having to be careful not to paste in a non-BMP character (a Tk limitation, I believe, and currently being tracked at issue 13153), I'm pretty happy with IDLE too. It's my standard way to fiddle with Python code. Easier to use than the inbuilt interactive mode, as Alt-P will recall an entire block command, rather than one line at a time. So, I echo that sentiment of thanks. :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
On 2/27/2014 7:07 AM, Mark H. Harris wrote: Oh, and one more thing... whoever is doing the work on IDLE these days, nice job! It is stable, reliable, and just works/ appreciate it! As one of 'them', thank you for the feedback. There are still some bugs, but I hit them seldom enough that I am now looking at enhancement issues. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Tuples and immutability
On Thu, Feb 27, 2014 at 10:27 AM, Eric Jacoboni wrote:
> Le 27/02/2014 17:13, Zachary Ware a écrit :
>>
>> You're not the first person to have this question :)
>>
>> http://docs.python.org/3/faq/programming.html#why-does-a-tuple-i-item-raise-an-exception-when-the-addition-works
>>
>
> Oh yes, i was aware of this explanation (thanks to Chris for his answer,
> too)... and that's why i wrote "reasonable" :)
> I know i should use append() or extend() and i understand the tricky
> implications of += in this context. But, imho, it's far from being a
> intuitive result, to say the least.
Well, once you understand what's actually going on, it's the result
that you should expect. The FAQ entry I linked to exists to help
people get to that point.
To answer your specific questions:
> But, then, why a_tuple is still modified?
It is not. a_tuple is still "('spam', , 'eggs')", exactly the same before and after the attempted
"a_tuple[1] += [20]". The change is internal to .
> I get a TypeError for an illegal operation, but this operation is still
> completed?
Half completed. The extension of
happened as expected, but the assignment of to a_tuple[1] didn't. It looks like it did, though, because
the assignment was just trying to assign the same object to the same
index.
--
Zach
--
https://mail.python.org/mailman/listinfo/python-list
Re: Tuples and immutability
On Fri, Feb 28, 2014 at 3:27 AM, Eric Jacoboni wrote: > But, imho, it's far from being a intuitive result, to say the least. It's unintuitive, but it's a consequence of the way += is defined. If you don't want assignment, don't use assignment :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Tuples and immutability
Le 27/02/2014 17:13, Zachary Ware a écrit : > > You're not the first person to have this question :) > > http://docs.python.org/3/faq/programming.html#why-does-a-tuple-i-item-raise-an-exception-when-the-addition-works > Oh yes, i was aware of this explanation (thanks to Chris for his answer, too)... and that's why i wrote "reasonable" :) I know i should use append() or extend() and i understand the tricky implications of += in this context. But, imho, it's far from being a intuitive result, to say the least. -- https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
On 27 February 2014 15:42, Mark H. Harris wrote:
> On Thursday, February 27, 2014 8:42:55 AM UTC-6, Oscar Benjamin wrote:
>
>>
>> Some points:
>
>Thanks so much... you have clarified some things I was struggling with...
>
>> 1) Why have you committed the code as a .tar.gz file?
>
> um, to save space... well, I know its tiny, but its just a habit I
> have... 5kb instead of 25kb...
It made it awkward for me to see the code you were referring to. In a
separate thread you asked about how to share code samples. These days
it's common practice to host code somewhere it can be viewed from a
browser. This means that I can do things like link to a line in Chris'
code:
https://github.com/Rosuav/ExceptExpr/blob/master/examples.py#L169
There are many other reasons (as mentioned by Chris) why committing a
binary archive instead of just the plain old files is a generally bad
idea with standard version control systems. A relevant one is that
every change you make to your code, even if you only change 2 lines
will require an additional 5kb of space to store the new .tar.gz file
alongside the old rather than 200 bytes or whatever it is to store the
diff of the code files.
>> 2) This function is not such a good idea:
>>
>> def D(numform):
>> return Decimal(str(numform))
>
> The reason for this is not for strings, but for float literals. All of
> my functions may take a float literal and things still work, because the
> D(float) function converts the float literal to a string, which is then
> passed to the Decimal constructor.so... this works sqrt(0.1) or,
> sqrt(2.01) Without the D() function float literals may not be passed to the
> Decimal because it really cannot handle them... 0.1 and others cause it a
> fit...is there another way to do what I'm looking for here..?
I think you're misunderstanding what's going on:
>>> from decimal import Decimal as D
>>> D(0.1)
Decimal('0.155511151231257827021181583404541015625')
There is no binary floating point value that is exactly equal to the
mathematical number 0.1. So when you write 0.1 in Python the number is
rounded to the nearest binary floating point number. When you create a
Decimal from a float it will create a Decimal with the *exact* same
value that the float had. That's exactly what you're seeing above.
When you print a float normally it pretends to have the value 0.1 but
that's really a lie:
>>> 0.1 # There is no float with the true value 0.1!
0.1
>>> 0.1 == D('0.1')
False
When you convert a float to a string it does not show the exact value
of the float but rather a rounded, shortened decimal form. By
converting float->str->Decimal you are introducing unnecessary
rounding. The Decimal constructor deliberately never rounds its inputs
and every float can be represented as a Decimal with a finite number
of digits. So Decimal(float) is exact but your D function is not.
It is precisely the fact that binary floating point cannot represent
seemingly simple non-integer decimal numbers like 0.1 that leads to
the creation of the decimal module. But why would anyone pass a float
into one of your dmath functions since they're surely much slower than
the math module? The main reason that I can imagine is that they would
like a really accurate result in which case rounding all floats on
input is unacceptable.
> This has confused me, because when I look into the module help text I
> don't see roun() all I see is
> __round__(...) how do I know when the round() method exists vs.
> __round__(...) ??
The round builtin function calls __round__ on any object. Dunder
methods are not supposed to be called directly.
Oscar
--
https://mail.python.org/mailman/listinfo/python-list
Re: Tuples and immutability
Eric Jacoboni : a_tuple[1] += [20] > Traceback (most recent call last): > File "", line 1, in > TypeError: 'tuple' object does not support item assignment > > [...] > > But, then, why a_tuple is still modified? That's because the += operator 1. modifies the list object in place 2. tries to replace the tuple slot with the list (even though the list hasn't changed) It's Step 2 that raises the exception, but the damage has been done already. One may ask why the += operator modifies the list instead of creating a new object. That's just how it is with lists. BTW, try: >>> a_tuple[1].append(20) >>> a_tuple[1].extend([20]) Try also: >>> a_tuple[1] = a_tuple[1] Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Tuples and immutability
On Fri, Feb 28, 2014 at 3:01 AM, Eric Jacoboni wrote:
> I'm using Python 3.3 and i have a problem for which i've still not found
> any reasonable explanation...
>
a_tuple = ("spam", [10, 30], "eggs")
a_tuple[1] += [20]
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: 'tuple' object does not support item assignment
>
> Ok... I accept this message as += is a reassignment of a_tuple[1] and a
> tuple is immutable...
>
> But, then, why a_tuple is still modified?
>
a_tuple
> ('spam', [10, 30, 20], 'eggs')
>
> I get a TypeError for an illegal operation, but this operation is still
> completed?
This is a common confusion.
The += operator does two things. First, it asks the target to please
do an in-place addition of the other operand. Then, it takes whatever
result the target gives back, and assigns it back into the target. So
with a list, it goes like this:
>>> foo = [10, 30]
>>> foo.__iadd__([20])
[10, 30, 20]
>>> foo = _
Note that the second step returned a three-element list. Then the +=
operator stuffs that back into the source. In the case of a list, it
does that addition by extending the list, and then returning itself.
The putting-back-into-the-target step fails with a tuple, because a
tuple's members can't be reassigned. But the list has already been
changed by that point. So, when you go to look at it, you see a
changed list.
You can call on this behaviour more safely by using the append() or
extend() methods.
>>> a_tuple = ("spam", [10, 30], "eggs")
>>> a_tuple[1].extend([20])
>>> a_tuple
('spam', [10, 30, 20], 'eggs')
>>> a_tuple = ("spam", [10, 30], "eggs")
>>> a_tuple[1].append(20)
>>> a_tuple
('spam', [10, 30, 20], 'eggs')
(append will add one more element, extend is roughly the same as you
had). Then you're not trying to assign to the tuple, but you're still
mutating the list.
Hope that helps!
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Tuples and immutability
On Thu, Feb 27, 2014 at 10:01 AM, Eric Jacoboni wrote:
> Hi,
>
> I'm using Python 3.3 and i have a problem for which i've still not found
> any reasonable explanation...
>
a_tuple = ("spam", [10, 30], "eggs")
a_tuple[1] += [20]
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: 'tuple' object does not support item assignment
>
> Ok... I accept this message as += is a reassignment of a_tuple[1] and a
> tuple is immutable...
>
> But, then, why a_tuple is still modified?
>
a_tuple
> ('spam', [10, 30, 20], 'eggs')
>
> I get a TypeError for an illegal operation, but this operation is still
> completed?
You're not the first person to have this question :)
http://docs.python.org/3/faq/programming.html#why-does-a-tuple-i-item-raise-an-exception-when-the-addition-works
--
Zach
--
https://mail.python.org/mailman/listinfo/python-list
Tuples and immutability
Hi,
I'm using Python 3.3 and i have a problem for which i've still not found
any reasonable explanation...
>>> a_tuple = ("spam", [10, 30], "eggs")
>>> a_tuple[1] += [20]
Traceback (most recent call last):
File "", line 1, in
TypeError: 'tuple' object does not support item assignment
Ok... I accept this message as += is a reassignment of a_tuple[1] and a
tuple is immutable...
But, then, why a_tuple is still modified?
>>> a_tuple
('spam', [10, 30, 20], 'eggs')
I get a TypeError for an illegal operation, but this operation is still
completed?
--
https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
On Fri, Feb 28, 2014 at 2:42 AM, Mark H. Harris wrote: >> 1) Why have you committed the code as a .tar.gz file? > > um, to save space... well, I know its tiny, but its just a habit I > have... 5kb instead of 25kb... When you commit changes, though, it has to treat it as a completely changed binary file - utterly opaque, and it destroys your space savings too. Normal source code diffs are tiny, and they're readable. Check out the history of this file; you can easily see every change I've made: https://github.com/Rosuav/ExceptExpr/commits/master/find_except_expr.py Click on any commit to see what happened there. It's hard to do that with .tar.gz blobs. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: posting code snippets
On 2014-02-27 04:13, Mark H. Harris wrote: > are there rules here about posting code snippets, or length > considerations, and so forth? Seems like there was a place to share > code snips outside of the message area? This is the internet, so you're welcome to post code as you please. However, be aware that - if it's on an external site, lots of potential respondants will shrug with an "I ain't got time for that" or assume that the code-pasting site won't keep the content around (possibly making answers useless/contextless in a couple years) and skip it - if it's inline but too long, lots of potential respondants will shrug with an "I ain't got time for that" and skip it, or flame you for filling their mailbox with junk People here on the list generally enjoy helping where they can, but are more likely to do so if you've made it as easy possible. So SSCCEs (as Chris & Jerry mentioned) are your best hope of getting a useful & friendly reply :-) -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
On Thursday, February 27, 2014 8:42:55 AM UTC-6, Oscar Benjamin wrote: > > Some points: Thanks so much... you have clarified some things I was struggling with... > 1) Why have you committed the code as a .tar.gz file? um, to save space... well, I know its tiny, but its just a habit I have... 5kb instead of 25kb... > 2) This function is not such a good idea: > > def D(numform): > return Decimal(str(numform)) The reason for this is not for strings, but for float literals. All of my functions may take a float literal and things still work, because the D(float) function converts the float literal to a string, which is then passed to the Decimal constructor.so... this works sqrt(0.1) or, sqrt(2.01) Without the D() function float literals may not be passed to the Decimal because it really cannot handle them... 0.1 and others cause it a fit...is there another way to do what I'm looking for here..? > 3) In many places you've written code like this: > > prec=dscale(getcontext().prec +7) > sqr = (D(x).sqrt()).__round__(prec) > retscale=dscale(prec) > The preferred way is: > with localcontext() as ctx: > ctx.prec += 7 > sqr = round(D(x).sqrt(), prec) Thanks... > i.e. use a context manager to restore the context even if an error > occurs and use the round builtin rather than the dunder method. This has confused me, because when I look into the module help text I don't see roun() all I see is __round__(...) how do I know when the round() method exists vs. __round__(...) ?? > 4) You shouldn't be using round/__round__ for precision rounding: it > uses decimal places rather than significant figures. If you want to > round to context precision just use unary +. i.e.: > return +sqr whoohoo! thank you. > 5) The Decimal.sqrt method already rounds to context precision. > There's no need to compute in higher precision and then round it > yourself (in fact you're invalidating the correctness of the rounding > by double-rounding like this). So really it's just: > def sqrt(x): > return Decimal(x).sqrt() ok... > > 6) You should organise it in such a way that you're not progressively > increasing the precision each time one function calls another. right... well, and if you look at the calls to my __atan__ funcs I am assuming that they are still in the context of the calling func atan() right...? so no need to even have the bump up in prec there. > > Oscar thanks Oscar, I really appreciate your comments marcus -- https://mail.python.org/mailman/listinfo/python-list
How to run multiple virtualenv in product server
I'm starting to learn virtualenv, I wonder how run python project developed in virtualenv. Here is my situation, there is a server we can access with a common user name and password, there are many py scripts wrote by different people on this server. If I develop my python project with virtualenv, could I run it in product server?? -- https://mail.python.org/mailman/listinfo/python-list
Re: posting code snippets
On Thursday, February 27, 2014 9:01:50 AM UTC-6, Jerry Hill wrote: > -- > > Jerry Thanks guys, perfect. 'preciate it! -- https://mail.python.org/mailman/listinfo/python-list
Re: posting code snippets
On Thu, Feb 27, 2014 at 7:13 AM, Mark H. Harris wrote: > hi folks, >Its been too long... can't remember... are there rules here about posting > code snippets, or length considerations, and so forth? Chris' advice about just posting your code inline with your message is good. If the problem is that you think your code is too long to post inline, you're probably right. That means it's probably also too long for people to give it much attention. If you really want people to help figure out what is going on with code you don't understand, the best thing to do is to post a Short, Self Contained, Correct Example (http://www.sscce.org/). That means cutting the code down to the bare minimum required to demonstrate your issue. Many times, the very act of cutting the code down to a digestible chunk will show you the problem without posting. And if you still don't understand what's going on, you're much more likely to get help when you present a problem that can be read in a single screenful or so of code. >A related question, is there a python repository for uploading py files, > patches, suggestions, etc? Assuming this goes beyond posting code for people on the list to look at, yes, there are lots of places to post python code. For short bits, Activestate has a repository of python recipes: http://code.activestate.com/recipes/langs/python/ For publishing full modules and packages, there's the python package index: https://pypi.python.org/pypi Patches, bugs and feature requests for the python language itself belong here: http://bugs.python.org/ attached to an appropriate tracker issue. Feature requests should probably be raised on the python-ideas mailing list (https://mail.python.org/mailman/listinfo/python-ideas) before opening an issue on the bug tracker. -- Jerry -- https://mail.python.org/mailman/listinfo/python-list
ANN: Python Job Board - Call for volunteers
[Please help spread the word by forwarding to other relevant mailing lists, user groups, etc. world-wide; thanks :-)] Dear Python Community, for many years, the Python Job board (http://legacy.python.org/community/jobs/) was run by volunteers - most of the time by just one volunteer at a time until they moved on to spend their time on other things. We've now reached such a point again. In these years, the volume on the job board has significantly increased, as it got more and more popular. It is now at around 2-5 postings per day and most of those positions get filled quickly - which is an indication of how useful this service is to the Python community. To scale up and revive the job board, the PSF would now like to setup a *team of volunteers* to run the job board and this is our call for help. How does the job board work ? - At the moment, the job board is maintained on the legacy site (http://legacy.python.org/community/jobs/), but since we've launched our brand new website (http://www.python.org/), we'd like to move the job board over to that site. Instead of the repository based approach used on the old site, the new site has database support to aid in more easily processing and filing job listings. There's a job board mailing list which helps coordinate the task of reviewing and filing job offers. Currently, all job submissions get sent to this mailing list, but with the job board app, the submission process can be moved over to the website's database. What does it take to run the job board ? You have to review the job postings, request changes if they are too long, don't clearly state the need for Python skills, or have quality issues. After review, the job board app will then allow posting the jobs on the website by simply setting the status to published. Communication with the submitters is usually done by email and via the mailing list, so all team members can see the communication and help out if necessary. Please note: This is just a high level overview. The details need to be hashed out by the new team. Does the job board app work already ? - It does, but is disabled at the moment due to lack of volunteers. Since the site just launched there may also well be some issues with the job board app. On the positive side there's a lot happening around the site at the moment, so if you have change requests, these will usually be implemented quickly - or you can jump in, hack on the job board app and submit a pull request yourself: https://github.com/python/pythondotorg/tree/master/jobs These are exciting times and this is your chance to make a difference ! Ok, I like new challenges - where do I sign up ? Great :-) Please write to j...@python.org I have a question... If you have questions, you can write me or the PSF board at p...@python.org. Many thanks, -- Marc-Andre Lemburg Director Python Software Foundation http://www.python.org/psf/ -- https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
On 27 February 2014 12:07, Mark H. Harris wrote: > > I have created a project here: > > https://code.google.com/p/pythondecimallibrary/ > > I wrote a dmath.py library module for use with the C accelerated decimal > module, that I would like to see merged into the C Python distribution so > that folks have it by default... without having to pull it down with GIT, or > whatever. Hi Mark, Some points: 1) Why have you committed the code as a .tar.gz file? 2) This function is not such a good idea: def D(numform): return Decimal(str(numform)) The Decimal constructor already accepts strings and many types of numbers. Going via str like this reduces accuracy if e.g. someone passes a float in. 3) In many places you've written code like this: prec=dscale(getcontext().prec +7) sqr = (D(x).sqrt()).__round__(prec) retscale=dscale(prec) The preferred way is: with localcontext() as ctx: ctx.prec += 7 sqr = round(D(x).sqrt(), prec) i.e. use a context manager to restore the context even if an error occurs and use the round builtin rather than the dunder method. 4) You shouldn't be using round/__round__ for precision rounding: it uses decimal places rather than significant figures. If you want to round to context precision just use unary +. i.e.: return +sqr 5) The Decimal.sqrt method already rounds to context precision. There's no need to compute in higher precision and then round it yourself (in fact you're invalidating the correctness of the rounding by double-rounding like this). So really it's just: def sqrt(x): return Decimal(x).sqrt() 6) You should organise it in such a way that you're not progressively increasing the precision each time one function calls another. Oscar -- https://mail.python.org/mailman/listinfo/python-list
Re: Can global variable be passed into Python function?
On Friday, February 21, 2014 12:37:59 AM UTC-6, Sam wrote: > I need to pass a global variable into a python function. However, the global > variable does not seem to be assigned after the function ends. Is it because > parameters are not passed by reference? How can I get function parameters to > be passed by reference in Python? def func(x): global ref_name ref_name = '3.14159' # rest of the code # rest of the code When you call this function the ref_name reference will be set to '3.14159' as a string and your main code will be able to 'see' it, and other funcs will be able to 'see' it too... play with it a bit... if other funcs need to write to it they will also have to use the global ref_name line. As long as other funcs only read the reference, then the global line is not needed to 'see' the reference. As others have noted, python does not have a 'variable' concept (references to objects instead) and so your question is a little ambiguous. Also, using global references within functions is not a good idea... generally speaking. Cheers -- https://mail.python.org/mailman/listinfo/python-list
Re: SSH/Telnet program to Router/switch
Sent from my iPhone > On Feb 20, 2014, at 5:59 AM, Ferrous Cranus wrote: > > Τη Τετάρτη, 19 Φεβρουαρίου 2014 10:45:53 π.μ. UTC+2, ο χρήστης Wojciech > Łysiak έγραψε: >>> On 19.02.2014 09:14, Sujith S wrote: >>> >>> Hi, >> >> >>> I am new to programming and python. I am looking for a python script to do >>> ssh/telnet to a network equipment ? I know tcl/perl does this using >>> expect/send. >> >> >>> Do we have expect available in python as well or need to use some other >>> method ? >> >> >> >> Hello, >> >> If you are looking for a way to connect to your netdevices and then >> >> execute some shell commands (with output) via ssh then google for >> >> paramiko module for python. >> >> >> >> It works on windows and linux. >> >> >> >> -- >> >> BR, >> >> Wojtek > > Hello, > > What will benefit the OP to go ahead and use paramiko opposed to just use > "Putty" or another perhaps even Chrome based ssh client? > > Is there an advantage to that? This is a Python mailing list so obviously the OP wants to use python to automate logging into his devices and dispatching some commands. Why else would they ask here? > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: posting code snippets
On Thu, Feb 27, 2014 at 11:13 PM, Mark H. Harris wrote: > hi folks, >Its been too long... can't remember... are there rules here about posting > code snippets, or length considerations, and so forth? >Seems like there was a place to share code snips outside of the message > area? The convention is to post it in-line, just have it right there in the body of the email. There's no specific rule on length, but if it goes over a screenful or two, a lot of people won't bother to read it. Keeping the code in the message itself is the best way to carry it around. Not every transmission medium supports attachments, and they don't cut down on size in any way; and a link to an external resource creates a dependency. But if your code really is too long to be practical, you could post it to pastebin or somesuch. It's not as good as keeping it in the email, but it can work. Do try to make your code more consumable, though - posting a link to a thousand-line script is just as useless as embedding it, as nobody will bother to read through it. > tnx... happy Thursday! I never could get the hang of Thursdays. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
posting code snippets
hi folks, Its been too long... can't remember... are there rules here about posting code snippets, or length considerations, and so forth? Seems like there was a place to share code snips outside of the message area? A related question, is there a python repository for uploading py files, patches, suggestions, etc? What is the correct venue protocol for contributing code source? tnx... happy Thursday! -- https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
On Wednesday, February 19, 2014 4:10:22 PM UTC-6, Terry Reedy wrote: > Or just dmath. I think this is a better idea than suggesting additions > to decimal itself. For one thing, anything put in decimal would be > subject to change if the function were to be added to the standard. It > is worth noting in such a posting that Krah's speedup make such > functions really feasible. The algorithms could be similar, at least > initially, to the one used for floats > > Terry Jan Reedy I have created a project here: https://code.google.com/p/pythondecimallibrary/ I wrote a dmath.py library module for use with the C accelerated decimal module, that I would like to see merged into the C Python distribution so that folks have it by default... without having to pull it down with GIT, or whatever. Anyway, thanks for responding (everyone) and for your consideration. Oh, and one more thing... whoever is doing the work on IDLE these days, nice job! It is stable, reliable, and just works/ appreciate it! Kind regards, Mark H Harris -- https://mail.python.org/mailman/listinfo/python-list
Re: exec and locals
On Thu, Feb 27, 2014 at 10:29 PM, Gregory Ewing wrote: > Steven D'Aprano wrote: >> >> On Thu, 27 Feb 2014 16:34:33 +1300, Gregory Ewing wrote: >> >>> Why not just use this version all the time? It should work in both 2.x >>> and 3.x. >> >> >> Because that's yucky. It's an aesthetic thing: when supported, I want the >> Python interpreter to manage the context manager. > > > More yucky than wrapping the Py3 version in an > exec? To my way of thinking, that cancels out any > elegance that might have been gained from using > a with-statement. > > Do you really need to use the context manager > at all? Could you just write the try-statement > that you would have written in Py2 if you > didn't have a context manager? If I have to support two vastly different versions, I would prefer (when possible) to write the code so that dropping the old version's support is simply a matter of deleting stuff. Write the code for the new version, then warp it as little as possible to support the old version as well, and keep it clear which bits are for the old. Writing code that avoids 'with' altogether goes against that. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: exec and locals
Steven D'Aprano wrote: On Thu, 27 Feb 2014 16:34:33 +1300, Gregory Ewing wrote: Why not just use this version all the time? It should work in both 2.x and 3.x. Because that's yucky. It's an aesthetic thing: when supported, I want the Python interpreter to manage the context manager. More yucky than wrapping the Py3 version in an exec? To my way of thinking, that cancels out any elegance that might have been gained from using a with-statement. Do you really need to use the context manager at all? Could you just write the try-statement that you would have written in Py2 if you didn't have a context manager? -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Python : parsing the command line options using optparse
> > They must be running an older version of FreeBSD since the default version > of python is 2.7. > > There is a FreeBSD package for argparse, the command would be something > like >pkg_add -r install py26-argparse > > > Rod > > Yes Iam running a older version of FreeBSD ( Iam actually running a derivative of FreeBSD ) Thanks for the suggestion I ran the command but I got the below error # pkg_add -r install py26-argparse Error: Unable to get ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-7-stable/Latest/install.tbz: File unavailable (e.g., file not found, no access) pkg_add: unable to fetch ' ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-7-stable/Latest/install.tbz' by URL Error: Unable to get ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-7-stable/Latest/py26-argparse.tbz: File unavailable (e.g., file not found, no access) pkg_add: unable to fetch ' ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-7-stable/Latest/py26-argparse.tbz' by URL Iam now trying to browse the link directly didnt find the patch , will keep you posted -- https://mail.python.org/mailman/listinfo/python-list
Re: end quote help for a newbie
On Thu, Feb 27, 2014 at 9:30 PM, Peter Clark wrote:
> Hi, I have just started trying to use python version 3, under windows XP, I
> have got a simple script (attached) to run as I want in Interpreter mode.
> It is saved as a .py file. If I double click on the file the python screen
> opens and appears to be waiting for input but the cursor just sits there
> without doing anything but blink. I haven't found any .py program which does
> anything except open and close the python window, or occasionally accepting
> input with no response.
In future, it'd be easier for us if you include the text inline. It's
not particularly long, so I'll just do that for you here.
# Dragons and dungeons, based on CP/M program messages from ca. 1966
# This version designed and produced by peter clark beginning in December 2013
def startandload(n):# introduce program and allow messages to be
loaded/amended
x = str(input("Welcome Adventurer, what is your name?"))
if x==('load'):
y = str(input("messages, places or things?"))
if y in("messages", "places","things"):
print("OK")
else: print("Wrong")
if x==('restart'):
y = str(input("game reference"))
if y in("messages", "places","things"):
print("*** to be done - load and restart game ***")
else: print("Wrong")
while True:
startandload
The problem is right at the end: you don't actually call the function.
You always need parentheses to call a function. I'm also a bit
confused as to your reason for running a function called
"startandload" (which seems to be initialization) in an infinite loop;
you possibly just want to call it once.
Note that input() already returns a string, so passing it through
str() doesn't do anything.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
On Wednesday, February 19, 2014 4:29:27 PM UTC-6, Oscar Benjamin wrote: > Actually the performance difference isn't as big as you might think. > > Oscar You're right. At least my own benchmark on my native exp() vs the built-in was about ~same ~same. I was hoping that Stefan had used FFT... but I need to talk with him... Thanks for the reply. -- https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
> > Have you looked at the gmpy2 ( https://code.google.com/p/gmpy/ ) module? > > casevh No... was not aware of gmpy2... looks like a great project! I am wondering why it would be sooo much faster? I was hoping that Stefan Krah's C accelerator was using FFT fast fourier transforms for multiplication at least... but, as Oscar pointed out a native python series algorithm runs right along with the built-in (at least for exp() and ln() ) I have not looked at Krah's code, so not sure what he did to speed things up... (something more than just writing it in C I would suppose). Thanks for the heads up on gmpy -- https://mail.python.org/mailman/listinfo/python-list
Re: Deepcopying a byte string is quicker than copying it - problem?
On 27.02.14, 7:30 , Frank Millman wrote:
> Hi all
>
> I noticed this a little while ago, but dismissed it as a curiosity.
> On reflection, I decided to mention it here in case it indicates a
> problem.
>
> This is with python 3.3.2.
>
> C:\>python -m timeit -s "import copy" "copy.copy('a'*1000)" 10
> loops, best of 3: 6.91 usec per loop
>
> C:\>python -m timeit -s "import copy" "copy.deepcopy('a'*1000)"
> 10 loops, best of 3: 11.8 usec per loop
>
> C:\>python -m timeit -s "import copy" "copy.copy(b'a'*1000)" 1
> loops, best of 3: 79.9 usec per loop
>
> C:\>python -m timeit -s "import copy" "copy.deepcopy(b'a'*1000)"
> 10 loops, best of 3: 11.7 usec per loop
>
> As you can see, deepcopying a string is slightly slower than
> copying it.
>
> However, deepcopying a byte string is orders of magnitude quicker
> than copying it.
>
> Actually, looking closer, it is the 'copy' that is slow, not the
'deepcopy'
> that is quick..
>
> Expected, or odd?
>
> Frank Millman
>
>
>
Indeed, just tried this:
Python 3.3.2 (default, Sep 30 2013, 21:37:29)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.75)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import copy
>>>
>>> bs = b'a'*1000 id(bs)
140246553640960
>>> id(copy.copy(bs)) # WATCH THIS!
140246578636800
>>> id(copy.deepcopy(bs))
140246553640960
>>> id(bs[:])
140246553640960
>>>
>>> us = 'a'*1000 id(us)
140246553642496
>>> id(copy.copy(us))
140246553642496
>>> id(copy.deepcopy(us))
140246553642496
>>> id(us[:])
140246553642496
Interesting; copy.copy(b'bytes') creates a "real" copy of an otherwise
immutable value... That might actually be some form of a bug.
By the way, if you are looking into this as something about speed, you
should use slices, not copy.copy/deepcopy, anyways (copy = bc[:]);
More than 5x faster:
$ python -m timeit -s "import copy; s='a'*1000" "copy.copy(s)"
100 loops, best of 3: 0.465 usec per loop
$ python -m timeit -s "import copy; s='a'*1000" "cs = s[:]"
1000 loops, best of 3: 0.0728 usec per loop
--
https://mail.python.org/mailman/listinfo/python-list
Re: end quote help for a newbie
On Thursday, 30 January 2014, 21:27, Peter Clark wrote:
Thank-you. Please no-one reply to this post. I just want to put on record my
complete p-offed-ness, that having spent 10 days sorting out and hypertexting a
library of documentation, I now have to start all over.
Please do not respond, I am sure it is all my fault.
Please do not respond - it will only prolong the agony.
Long live the Norwegian blue.
peter
On Thursday, 30 January 2014, 17:31, Zachary Ware
wrote:
Please reply to the list, rather than to me directly. You can use
"Reply to List" if you have that option, or "Reply to All" to make
sure you include the list.
On Thu, Jan 30, 2014 at 8:52 AM, Peter Clark wrote:
> I do not know how to dump the screen - it will not let me select anything
> with the mouse cursor, so here is my (typed in) reproduction:
Since it looks like you're probably using Windows Command
Prompt, you
can right click anywhere in that window, click "Mark", and highlight a
rectangle containing what you want and hit the Enter key. Note that
it doesn't go by lines, only the rectangle you highlight will be
copied! (Yes, it is horribly annoying :)
Thank you for taking the time to type it all out!
> Python 3.3.3 (v3.3.3:c3896275c0f6, Nov 18 2013, 21:18:40) [MSC v.1600 32
> bit (In
> tel) on win32
> Type "help", "copyright", "credits" or "license" for more information.
print "xyz"
> File "(stdin)", line 1
> print "xyz"
> ^
> SyntaxError: invalid syntax
This right here confirms what I thought: you're using Python 3 with a
Python 2 tutorial. 'print' in Python 3 is a function just like
'input' or 'open', so you have to use it like this instead:
>>> print("xyz")
xyz
print '''xyz" . . .'''
> File "(stdin)", line 1
> print '''xyz'''
> ^
> SyntaxError: invalid syntax
print '''xyz" . . .'' (note - not appearing on
screen - this is 2 single quotes)
> ... '''
> File "(stdin)", line 2
> '''
> ^
> SyntaxError: invalid syntax
>
> I do not see anywhere a definition of which version the tutorial relates to,
> but I downloaded it from the Python site on 19th January 2014.
The Python website provides docs for every current version of Python,
and the community is currently in the midst of a very long transition
from version 2.7 to 3.x, so both versions are considered "current".
In fact, most links to the Python documentation will link to the 2.7
version to maintain compatibility. Here's
a link to the Python 3
version of the tutorial, which should work much better for you!
http://docs.python.org/3/tutorial/
You can also find the docs in your Python installation: find Python
3.3 in your start menu, and choose "Python Manuals". This will open
the same docs as are found online, in standard Windows help file
format. Click the "Tutorial" link on the first page of that, and you
should have the right tutorial to work from.
Hope this helps, and welcome to Python!
--
Zach
>
> peter.
>
> On Thursday,
30 January 2014, 16:13, Zachary Ware
> wrote:
>
> On Thu, Jan 30, 2014 at 7:26 AM, Peter Clark wrote:
>
>> There is probably an easy solution to this – but I have not found it.
>>
>> Trying to terminate a literal in a print statement (from the tutorial).
>>
>> The literal should be enclosed in double quotes “ “
>>
>> the initial double quote seems to be OK (if I use a different character it
>> flags it) but the ending is flagged as invalid syntax.
I have tried
>> changing my keyboard from UK to USA, without any effect, and tried adding
>> a
>> space after the final double quote,
>
>
> Which version of Python are you using? Make sure you're using the
> same version of interpreter and tutorial. 'print' was one of the big
> changes between Python 2 and Python 3 (in Python 2 it was a statement,
> while in Python 3 it is a function), so a tutorial written with Python
> 2 in mind will have some issues if you're using Python 3.
>
> If you've already checked that, try copying and pasting your entire
> interpreter session into a reply here, and we'll be more able to
> figure out what's going on.
>
> Hope this helps,
>
> --
> Zach
>
Hi, I have just started trying to use python version 3, under windows XP, I
have got a simple script (attached) to run as I want in Interpreter mode. It
is saved as a .py file. If I double click on the file the python screen opens
and appears to be waiting for input but the cursor just sits there without
doing anything but blink. I haven't found any .py program which does anything
except open and close the python window, or occasionally accepting input with
no response.
I would like to be able to save and run scripts as my usual method of acquiring
a new language, but getting python to run a saved script has me beat. I assume
there is something I am missing, or have missed.
As an aside, does the fact that python runs at all indicat
Re: exec and locals
On Thu, 27 Feb 2014 00:31:56 +, Steven D'Aprano wrote: > On Wed, 26 Feb 2014 14:00:59 +, Alister wrote: > >> On Wed, 26 Feb 2014 13:15:25 +, Steven D'Aprano wrote: >> >>> I have to dynamically generate some code inside a function using exec, >>> but I'm not sure if it is working by accident or if I can rely on it. > [...] > >> I have no idea but as exec is generally considered to be a bad idea are >> you absolutely sure this is the correct way to achieve your end goal? >> >> perhaps if you detailed your requirement someone may be able to suggest >> a safer solution. > > Thanks for your concern, but what I'm doing is perfectly safe. The > string being exec'ed is a string literal known at compile-time and > written by me (see my previous email for details) and the only reason > I'm running it with exec at runtime rather than treating it as normal > source code is that it relies on a feature that may not be available > (with statement). > > The joys of writing code that has to run under multiple incompatible > versions of Python. I hadn't noticed who had made the original post or a I wouldn't have bothered, you know Python & what is safe far better than I ever will -- The world is not octal despite DEC. -- https://mail.python.org/mailman/listinfo/python-list
Re: Deepcopying a byte string is quicker than copying it - problem?
"Frank Millman" wrote in message
news:lemm11$18r$1...@ger.gmane.org...
> Hi all
>
> I noticed this a little while ago, but dismissed it as a curiosity. On
> reflection, I decided to mention it here in case it indicates a problem.
>
> This is with python 3.3.2.
>
> C:\>python -m timeit -s "import copy" "copy.copy('a'*1000)"
> 10 loops, best of 3: 6.91 usec per loop
>
> C:\>python -m timeit -s "import copy" "copy.deepcopy('a'*1000)"
> 10 loops, best of 3: 11.8 usec per loop
>
> C:\>python -m timeit -s "import copy" "copy.copy(b'a'*1000)"
> 1 loops, best of 3: 79.9 usec per loop
>
> C:\>python -m timeit -s "import copy" "copy.deepcopy(b'a'*1000)"
> 10 loops, best of 3: 11.7 usec per loop
>
> As you can see, deepcopying a string is slightly slower than copying it.
>
> However, deepcopying a byte string is orders of magnitude quicker than
> copying it.
>
> Actually, looking closer, it is the 'copy' that is slow, not the
> 'deepcopy' that is quick..
>
> Expected, or odd?
>
> Frank Millman
>
Thanks, Ian and Peter, for confirming that this is not expected.
I have created an issue on the bug tracker -
http://bugs.python.org/issue20791
Frank
--
https://mail.python.org/mailman/listinfo/python-list
Re: Deepcopying a byte string is quicker than copying it - problem?
Frank Millman wrote:
> Hi all
>
> I noticed this a little while ago, but dismissed it as a curiosity. On
> reflection, I decided to mention it here in case it indicates a problem.
>
> This is with python 3.3.2.
>
> C:\>python -m timeit -s "import copy" "copy.copy('a'*1000)"
> 10 loops, best of 3: 6.91 usec per loop
>
> C:\>python -m timeit -s "import copy" "copy.deepcopy('a'*1000)"
> 10 loops, best of 3: 11.8 usec per loop
>
> C:\>python -m timeit -s "import copy" "copy.copy(b'a'*1000)"
> 1 loops, best of 3: 79.9 usec per loop
>
> C:\>python -m timeit -s "import copy" "copy.deepcopy(b'a'*1000)"
> 10 loops, best of 3: 11.7 usec per loop
>
> As you can see, deepcopying a string is slightly slower than copying it.
>
> However, deepcopying a byte string is orders of magnitude quicker than
> copying it.
>
> Actually, looking closer, it is the 'copy' that is slow, not the
> 'deepcopy' that is quick..
>
> Expected, or odd?
Definitely odd. For some reason deepcopy() special-cases the bytes type
while copy() does not. If you fix that:
$ python3.4 -m timeit -s 'import copy; b = b"a"*1000' 'copy.copy(b)'
1 loops, best of 3: 21.2 usec per loop
$ python3.4 -m timeit -s 'import copy; copy._copy_dispatch[bytes] =
copy._copy_immutable; b = b"a"*1000' 'copy.copy(b)'
100 loops, best of 3: 0.971 usec per loop
I think this an oversight rather than intentional. Please report to
bugs.python.org.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Deepcopying a byte string is quicker than copying it - problem?
On Wed, Feb 26, 2014 at 11:30 PM, Frank Millman wrote:
> Hi all
>
> I noticed this a little while ago, but dismissed it as a curiosity. On
> reflection, I decided to mention it here in case it indicates a problem.
>
> This is with python 3.3.2.
>
> C:\>python -m timeit -s "import copy" "copy.copy('a'*1000)"
> 10 loops, best of 3: 6.91 usec per loop
>
> C:\>python -m timeit -s "import copy" "copy.deepcopy('a'*1000)"
> 10 loops, best of 3: 11.8 usec per loop
>
> C:\>python -m timeit -s "import copy" "copy.copy(b'a'*1000)"
> 1 loops, best of 3: 79.9 usec per loop
>
> C:\>python -m timeit -s "import copy" "copy.deepcopy(b'a'*1000)"
> 10 loops, best of 3: 11.7 usec per loop
>
> As you can see, deepcopying a string is slightly slower than copying it.
>
> However, deepcopying a byte string is orders of magnitude quicker than
> copying it.
>
> Actually, looking closer, it is the 'copy' that is slow, not the 'deepcopy'
> that is quick..
>
> Expected, or odd?
This will shed some light:
>>> a = 'a' * 1000
>>> b = copy.copy(a)
>>> a is b
True
>>> c = copy.deepcopy(a)
>>> a is c
True
>>> d = b'a' * 1000
>>> e = copy.copy(d)
>>> d is e
False
>>> f = copy.deepcopy(d)
>>> d is f
True
For some reason, calling copy.copy on a bytes object actually copies
the bytes, rather than just returning the immutable object passed in.
That's probably not intentional and is worth opening a ticket for.
The difference between copy and deepcopy is probably just due to the
extra overhead of deepcopy.
--
https://mail.python.org/mailman/listinfo/python-list
