How to use the returned telnet object after creating the telnet session.
Hello all,
First I would like thank you for creating such good platform for discussing
python..!!!
Assume that I will pass IP and port information from a function to open the
telnet session. have opened the telnet session and after opening the telnet
session I returned telnet object to calling function.
Now in the calling function If I use that object to read or write to terminal
I'm getting ERROR "AttributeError: 'NoneType' object has no attribute
'read_very_eager'".
#Open telnet connection to devices
def open_telnet_conn(dname,ip,port):
try:
TELNET_PORT = port
TELNET_TIMEOUT = 5
READ_TIMEOUT = 5
cmd = "show config"
#Logging into device
connection=telnetlib.Telnet(ip, TELNET_PORT, TELNET_TIMEOUT)
time.sleep(1)
connection.write(cmd + "\n")
#Here I'm able to write to connection object..
connection.write("\n")
time.sleep(2)
router_output = connection.read_very_eager()
print router_output
return(connection)
except IOError:
print "Input parameter error! Please check username, password and file
name."
#Function to read device IP and port . and this info for opening the telnet
session.
def IP_port(file):
T = []
F = open(file,'r')
F.seek(0)
line=F.read()
tuples = re.findall(r'(.+?)\s+(.+?)\s+(\d+)',line)
#(dname,IP,port)= tuples
for (dname,ip,port) in tuples:
T1=open_telnet_conn(dname,ip,port)
#HERE I will get the telnet object point to the same location as the
connection object. But I'm unable to write or read anything here. I think need
to convert the object T1 to TELNET CLASS object type..
print T1
T1.write("show config") https://mail.python.org/mailman/listinfo/python-list
Re: How to use the returned telnet object after creating the telnet session.
On Sun, 13 Sep 2015 00:38:03 -0700, manjunatha.mahalingappa wrote: > Assume that I will pass IP and port information from a function to open > the telnet session. have opened the telnet session and after opening the > telnet session I returned telnet object to calling function. > > Now in the calling function If I use that object to read or write to > terminal I'm getting ERROR "AttributeError: 'NoneType' object has no > attribute 'read_very_eager'". My best guess would be that something failed and has returned None instead of the object / class you're expecting. -- Denis McMahon, [email protected] -- https://mail.python.org/mailman/listinfo/python-list
Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
On Sat, Sep 12, 2015 at 9:58 PM, Tim Peters wrote: > > That's why I believe PEP 495 followed by the implementation > > of fold-aware "as intended" tzinfos (either within stdlib or by third > > parties) is the right approach. > > Me too - except I think acceptance of 495 should be contingent upon > someone first completing a fully functional (if not releasable) > fold-aware zoneinfo wrapping. Good idea. How far are you from completing that? > Details have a way of surprising, and > we should learn from the last time we released a tzinfo spec in the > absence of any industrial-strength wrappings using it. I completely agree. That's why I am adding test cases like Lord Hope Island and Vilnius to datetimetester. I will try to create a zoneinfo wrapping prototype as well, but I will probably "cheat" and build it on top of pytz. -- https://mail.python.org/mailman/listinfo/python-list
Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
On Sat, Sep 12, 2015 at 6:24 PM, Guido van Rossum wrote: > The repeated claims (by Alexander?) that astimezone() has the power of > pytz's localize() need to stop. Prove me wrong! :-) > Those pytz methods work for any (pytz) timezone -- astimezone() with a > default argument only works for the local time zone. That's what os.environ['TZ'] = zonename is for. The astimezone() method works for every timezone installed on your system. Try it - you won't even need to call time.tzset()! > (And indeed what it does is surprising, except perhaps to pytz users.) That I agree with. Which makes it even more surprising that I often find myself and pytz advocates on the opposite sides of the fence. Granted, setting TZ is a silly trick, but one simple way to bring a full TZ database to Python is to allow .astimezone() take a zonename string like 'Europe/Amsterdam' or 'America/Montevideo' as an argument and act as os.environ['TZ'] = zonename; t.astimezone() does now, but without messing with global state. I made this suggestion before, but I find it inferior to "as intended" tzinfos. The only real claim that I am making is that fictitious fixed offset timezones are useful and we already have some support for them in stdlib. The datetime.timezone instances that .astimezone() attaches as tzinfo are not that different from the instances that are attached by pytz's localize and normalize methods. In fact, the only major differences between datetime.timezone instances and those used by pytz is that pytz's EST and EDT instances know that they come from America/New_York, while datetime.timezone instances don't. That's why once you specify America/New_York in localize, your tzinfo.normalize knows it implicitely, while in the extended .astimezone() solution you will have to specify it again. This is not a problem when you only support one local timezone, but comes with a different set of tradeoffs when you have multiple timezones. One advantage of not carrying the memory of the parent zoneinfo in the fixed offset tzinfo instance is that pickling of datetime objects and their interchange between different systems becomes simpler. A pickle of a datetime.timezone instance is trivial - same as that of a tuple of timedelta and a short string, but if your fixed offset tzinfo carries a reference to a potentially large zoneinfo structure, you get all kinds of interesting problems when you share them between systems that have different TZ databases. In any case, there are three approaches to designing a TZ database interface in the datetime module: the "as intended" approach, the pytz approach and the astimezone(zonename:str) approach. The last two don't require a fold attribute to disambiguate end-of-dst times and the first one does. With respect to arithmetic, the last two approaches are equivalent: both timeline and classic arithmetics are possible, but neither is painless. The "as intended" approach comes with classic arithmetic that "just works" and encourages the best practice for timeline arithmetic: do it in UTC. That's why I believe PEP 495 followed by the implementation of fold-aware "as intended" tzinfos (either within stdlib or by third parties) is the right approach. -- https://mail.python.org/mailman/listinfo/python-list
Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
On Sat, Sep 12, 2015 at 10:25 PM, Tim Peters wrote: > > I will try to create a zoneinfo wrapping prototype as well, but I will > > probably "cheat" and build it on top of pytz. > > It would be crazy not to ;-) Note that Stuart got to punt on "the > hard part": .utcoffset(), since pytz only uses fixed-offset classes. > For a prototype - and possibly forever after - I'd be inclined to > create an exhaustive list of transition times in local time, parallel > to the list of such times already there in UTC. Yes. The only complication is that you need four transition points instead of two per year in a regular DST case: (1) start of gap; (2) end of gap; (3) start of fold; and (4) end of fold. Once you know where you are with respect to those points, figuring out utcoffset(), dst() and tzname() for either value of fold is trivial. > An index into either > list then gives an index into the other, and into the list of > information about the transition (total offset, is_dst, etc). Right. It's a shame though to work from a transitions in UTC list because most of DST rules are expressed in local times and then laboriously converted into UTC. I think I should also implement the POSIX TZ spec tzinfo. This is where the advantage of the "as intended" approach will be obvious. -- https://mail.python.org/mailman/listinfo/python-list
Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
On Sat, Sep 12, 2015, at 22:25, Tim Peters wrote: > That helps a lot, but "industrial-strength" implies "by algorithm". > There are far too many zones to deal with by crafting a hand-written > class for each. It occurs to me that though it's written in C, the zdump utility included in the tz code is implementation-agnostic w.r.t. what algorithm is used by the localtime function being tested. It's algorithm could probably be adapted to python. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
" Namespaces don't "become writeable". The purpose of "global" is to tell the compiler that this name should be bound in the global namespace, not the local namespace. " How does it become writeable then ? Bye, Skybuck. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
"Emile van Sebille" wrote in message news:[email protected]... On 9/11/2015 10:22 PM, Skybuck Flying wrote: I didn't learn anything from this posting, sorry ! ;) " I'm seeing a pattern here... " Only thing I might have learned from him was global namespace make thing writeable. But now somebody else says nope. So I can truely say nothing was learned. Explaining concepts to people takes something different. As far as I am concerned python works with objects like Delphi. And everything else is a reference to it. And the globals are somehow protected. But he's as clueless as everybody else seems to be. For me it doesn't matter since I will write python code just fine without understanding any of it. Bye, Skybuck. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
From what he wrote I can see he's not making much sense... Neither are you. Just lot's of nag and little python related stuff. Bye, Skybuck. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On Sun, 13 Sep 2015 10:04 pm, Skybuck Flying wrote: > " > Namespaces don't "become writeable". > > The purpose of "global" is to tell the compiler that this name should > be bound in the global namespace, not the local namespace. > " > > How does it become writeable then ? It's always writeable. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
"Steven D'Aprano" wrote in message news:[email protected]... On Sun, 13 Sep 2015 10:04 pm, Skybuck Flying wrote: " Namespaces don't "become writeable". The purpose of "global" is to tell the compiler that this name should be bound in the global namespace, not the local namespace. " How does it become writeable then ? " It's always writeable. " Thus my logic is correct. By making something global, it ends up in the global namespace, and it becomes writeable. I don't even understand how python interpreter works but I can understand it better than you guys do apperently hahaha. Bye, Skybuck. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
I may add to that: Just like most programmers don't truely understand what a compiler does ! HAHAHAHAHA. C programmers, Delphi programmers, Java programmers. What python's interpreter is doing same thing, probably completely irrelevant. Except when it comes to making changes to how python works ;) I don't need to know how the Python interpreter works, cause I will never change Python's implementation. However as indicated I did try to help out. Reversing the logic for python's global functioning should be possible. Bye, Skybuck. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On Sunday, September 13, 2015 at 8:11:13 AM UTC-4, Skybuck Flying wrote: > I don't even understand how python interpreter works but I can understand it > better than you guys do apperently hahaha. As tempting as it is to respond to Skybuck, with a brief pause to consider, and a deep breath, I'm sure we can all agree that there is no point in it. Skybuck: go in peace, and thanks for being part of the Python community. --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
In a message of Sat, 12 Sep 2015 22:15:02 -0400, Alexander Belopolsky writes: >I completely agree. That's why I am adding test cases like Lord Hope >Island and Vilnius to datetimetester. > >I will try to create a zoneinfo wrapping prototype as well, but I will >probably "cheat" and build it on top of pytz. My question, is whether it will handle Creighton, Saskatchewan, Canada? Creighton is an odd little place. Like all of Saskatchewan, it is in the Central time zone, even though you would expect it to be in the Mountain time zone based on its location on the globe. The people of Saskatchewan have decided not to adopt Daylight Savings time. Except for the people of Creighton (and nearby Denare Beach) -- who _do_ observe Daylight savings time. makes for an interesting corner case, one that I remember for personal (and not economic, or professional) reasons. Laura -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Sun, 13 Sep 2015 04:45 am, [email protected] wrote: > On 09/12/2015 10:32 AM, Steven D'Aprano wrote: >> On Sat, 12 Sep 2015 02:42 pm, Random832 wrote: >>[...] >> Computer science and IT is *dominated* by a single usage for "pointer" -- >> it's an abstract memory address. The fundamental characteristics of >> pointers are: > > Just upthread, you claimed something was "universally agreed" I did? "Universially agreed" doesn't sound like something I would say. Do you have a link to where I said that? I think you're confusing me with somebody else. Somebody who is not me. [...] >> Python, Java, Ruby, Lua, Javascript etc. have *no such concept* as >> pointer. There are no values in these languages which correspond to the >> standard definition of pointer: > > They have not such concept because the developers and documentors choose > not to describe that language that way. That does not mean one could not > come up with a perfectly valid description that did include the concept > of pointers. I have little problem with you using "pointer" as a metaphor: "Python variables are like pointers in these ways...". I do have a problem with you insisting that they are pointers. You can, if you choose, decide to change the meaning of the word "pointer". After all, as a general English term, it just means a type of dog. No, wait, that's the wrong meaning. It means anything which points in some fashion, like a dog. But as I said to Rurpy, if you're going to insist on using your own meanings for words, the onus is on you to ensure that people aren't going to misunderstand you. Sure, you could insist that `x = math.sin(1)` makes x a string, and justify that piece of obnoxious linguistic trickery by saying that x is a string of bits, but I think that we'd be justified in objecting to that misuse of terminology. Sure, you can insist that `x = math.sin(1)` makes x a pointer, but that too is a misuse of terminology. You can continue to call Python variables "pointers". After all, language is a construct, and words have no meaning but that we give them, and there is no law that says you are forbidden from using your own private meaning of words. And when you do, I shall continue to object vehemently to your wilful malapropism. [...] > It may not be appropriate way to describe Python for everybody but > it is perfectly reasonable (and even preferable) for people with > an understanding of "pointers" from some other language. And for > those people who don't then one could argue they are a clean slate > and using the word "pointer" won't hurt. No, it is not reasonable. You want to insist that `x = 23` in Python code makes x a pointer. But that Python snippet is analogous to to the following C and Pascal snippets: # C int x = 23; {Pascal} var x: integer; begin x := 23; end; Do you insist that they are pointers to? Then everything is a pointer, and the word has no meaning. Regardless of which of the three languages we are talking about, the assignment `x = 23` does not mean "bind some value to x which, when dereferenced, gives the value 23". The value bound to x is 23, not some indirect pointer to 23. The *implementation* of how names and variables are bound may (or may not) involve pointers, but that is outside of the language abstraction, whether we are talking about Python, C or Pascal. To call x a pointer to 23 breaks the language abstraction and confuses the (optional) implementation for the language interface: * CPython's implementation of namespaces may include a hash table, where the table's values are pointers to objects in the heap; * C's and Pascal's implementation of variables may include a compile-time table of variable names mapped to memory addresses; All three implementations may include a "thing-which-points" (Python name bindings may involve C pointers to objects implemented as C structs; Pascal and C variables may involve a compile-time table that points to the memory address of the variable being accessed), but NONE of them justifies calling x a pointer in ANY of those languages. If it helps you understand Python's programming model to discuss the implementation, by all means do so. But be clear that you are talking about *implementation* and not Python code. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Sun, 13 Sep 2015 10:50 pm, Steven D'Aprano wrote: > On Sun, 13 Sep 2015 04:45 am, [email protected] wrote: ... ^ > But as I said to Rurpy, Er, that would be you. Editing fail. Sorry about that. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.5.0 is now available
On behalf of the Python development community and the Python 3.5 release team, I'm proud to announce the availability of Python 3.5.0. Python 3.5.0 is the newest version of the Python language, and it contains many exciting new features and optimizations. You can read all about what's new in Python 3.5.0 here: https://docs.python.org/3.5/whatsnew/3.5.html And you can download Python 3.5.0 here: https://www.python.org/downloads/release/python-350/ Windows and Mac users: please read the important platform-specific "Notes on this release" section near the end of that page. We hope you enjoy Python 3.5.0! //arry/ -- https://mail.python.org/mailman/listinfo/python-list
Phone Tree
Hi, I'm helping out some teenagers (14yo ish) who have just started programming and are working on a 'call tree' program as part of some after school coding classes and I wanted to talk about potential solutions. The first task is to implement a 'troubleshooting program' similar to what a phone operator would have when you phone up with a problem. We all know the type when you phone up your ISP, 'have you turned it off and on again?', "have you changed your telephone filter' etc.. It states there should be at least 10 questions and that the user should reach a solution, e.g. 'replace your power cable'. There and my initial reaction was that this could be achieved by lots of if/else statements with each question running onto another one, ugly but it would certainly work. One of them pointed out how inefficient this was and asked if there was another way, they hated writing out tons of if/elif/else statements. Does anyone have any ideas for a more elegant solution? My thoughts are that I could use a tree data structure and hence make traversing the tree recursive based on yes or no answers. I'm happy to put the time in to explain these more complex ideas, I'm just hoping those with more expertise than myself could either help verify the idea or suggest alternatives. Thanks in advance! -- https://mail.python.org/mailman/listinfo/python-list
Integration using scipy odeint
Dear all I'm using Python 3.4.3. I am facing a problem in integrating using odeint solver. In the following code, tran is a function and in those are the variables which are arrays. These variables change their values with respect to time (the time which I pass to the function). I tried defining a loop inside the function, but Python throws an error saying float object not iterable. Please guide me how to solve this problem. #initial is an array containing initial values for the integration, dt is the time array with unequal time steps, which I have captured from other part of the code def tran(initial,dt): for i in dt: k1 [i] = 2.8e8 * math.exp(-21100/ta[i]) # k1,k2,k3 & k4 are constants which change according to temperature (ta), which in turn changes with respect to time. k2 [i] = 1.4e2 * math.exp(-12100/ta[i]) # ta changes its values according to dt, which is array. It runs from 0-6 with unequal time steps. k3 [i] = 1.4e5 * ta[i] * math.exp(-19680/ta[i]) # I've captured dt and all other arrays here from another loop, which is not of importtance. k4 [i] = 1.484e3 * ta[i] y = initial[0] z = initial[1] dn = (6*rho*initial[1]) dd = (math.pi*2000*initial[0]) ds = (dn/dd)**1/3 dydt = (166.2072*ta[i]*cca[i] - (1.447e13 * ta[i]**0.5 * rho**1/6 * y**1/6 * rho**1/6 * z**1/6 * 0.0832)) # cca,ta are arrays. y & z are 2 dependent variables dzdt = (k1[i]*ta[i]*cca[i]*12.011 + (21.2834*k2[i]*ta[i]*cca[i] * y**1/2 *ds) - (k3[i]*ta[i]*12.011*y*math.pi*ds**2 * cco[i]) - (phi*k4[i]*ta[i]*xo[i]*12.011*y*math.pi*ds**2)) return [dydt,dzdt] # dydt & dzdt are my final time integrated values initial = [0.01,1e-5] sol = odeint(tran, initial, dt) #this is my function call If I pass array in my function call, it says only length-1 can be converted to Python scalars. So I request all the experts in the group to tell me where I'm going wrong. Regards -- https://mail.python.org/mailman/listinfo/python-list
Re: Phone Tree
On Mon, Sep 14, 2015 at 12:39 AM, Azureaus wrote:
> The first task is to implement a 'troubleshooting program' similar to what a
> phone operator would have when you phone up with a problem. We all know the
> type when you phone up your ISP, 'have you turned it off and on again?',
> "have you changed your telephone filter' etc..
>
> It states there should be at least 10 questions and that the user should
> reach a solution, e.g. 'replace your power cable'. There and my initial
> reaction was that this could be achieved by lots of if/else statements with
> each question running onto another one, ugly but it would certainly work. One
> of them pointed out how inefficient this was and asked if there was another
> way, they hated writing out tons of if/elif/else statements.
>
> Does anyone have any ideas for a more elegant solution? My thoughts are that
> I could use a tree data structure and hence make traversing the tree
> recursive based on yes or no answers. I'm happy to put the time in to explain
> these more complex ideas, I'm just hoping those with more expertise than
> myself could either help verify the idea or suggest alternatives.
>
This sounds broadly similar to a Twenty Questions game. You may be
able to find some neat implementations of that, which could be
reworked into what you want.
A more cynical algorithm could be implemented as follows:
import random
questions = [
# The IT Crowd
"Hello, IT, have you tried turning it off and on again?",
# The Bastard Operator From Hell
"How long has this been happening?",
"Has anyone else had this problem?",
"Is it your floor that has the Gas Leak?",
# Standard ISP questions
"Have you tried disabling your antivirus?",
"Are we talking to the authorized account holder?",
# Add additional questions as required
]
random.shuffle(questions)
questions = questions[::2] # Ask about half of them
for q in questions:
response = input(q) # raw_input in Py2
# Utterly ignore the response
print("I'm sorry, nobody else has reported this problem, so it cannot
be a real problem.")
I may or may not be basing this on real life experience.
For something a bit more useful, though, what you might have is a
nested pile of tuples. For instance:
questions = (
# First the question
"Have you rebooted your computer?",
# Then the if-no response
"Please reboot your computer, then call back.",
# Finally the if-yes response
("Are you running Windows?",
("Are you using a Macintosh?",
"I'm sorry, we only support Windows and Mac OS.",
"Let me transfer you to our Macintosh support people.",
),
("Have you disabled your antivirus?",
"Please disable your AV and try again.",
("Is it your floor that has the gas leak?",
"I'm sorry, I can't help you.",
"Strike a match. All your problems will disappear.",
),
),
),
)
while isinstance(questions, tuple):
q, no, yes = questions
response = input(q)
if response == "yes": questions = yes
elif response == "no": questions = no
else: print("I'm sorry, I didn't understand that response.")
print(questions) # is now the solution
This is a data-driven algorithm. The code is extremely short, and is
fundamentally about the UI; you could change it completely (a GUI app,
text-to-speech and DTMF for IVR, etc, etc) without changing the
question structure at all.
Is this the kind of tree structure you had in mind?
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
[Alex] >>I will try to create a zoneinfo wrapping prototype as well, but I will >>probably "cheat" and build it on top of pytz. [Laura Creighton] > My question, is whether it will handle Creighton, Saskatchewan, Canada? > Creighton is an odd little place. Like all of Saskatchewan, it is > in the Central time zone, even though you would expect it to be > in the Mountain time zone based on its location on the globe. > The people of Saskatchewan have decided not to adopt Daylight > Savings time. Except for the people of Creighton (and > nearby Denare Beach) -- who _do_ observe Daylight savings time. > > makes for an interesting corner case, one that I remember for > personal (and not economic, or professional) reasons. Hi, Laura! By "zoneinfo" here, we mean the IANA (aka "Olson") time zone database, which is ubiquitous on (at least) Linux: https://www.iana.org/time-zones So "will a wrapping of zoneinfo handle XYZ?" isn't so much a question about the wrapping as about what's in the IANA database. Best guess is that Creighton's rules are covered by that database's America/Winnipeg entries. It's generally true that the database makes no attempt to name every location on the planet. Instead it uses names of the form "general/specific" where "general" limits the scope to some large area of the Earth (here "America" really means "North America"), and "specific" names a well-known city within that area. For example, I live in Ashland, Wisconsin (extreme far north in that state, on Lake Superior), but so far as IANA is concerned my time zone rules are called "America/Chicago" (some 460 air miles SSE, in a different state). Just for fun, I'll paste in the comments from the Saskatchewan section of IANA's "northamerica" data file (a plain text source file from which binary tzfiles like America/Chicago and America/Winnipeg are generated). You'll see Creighton mentioned if you stay alert ;-) # Saskatchewan # From Mark Brader (2003-07-26): # The first actual adoption of DST in Canada was at the municipal # level. As the [Toronto] Star put it (1912-06-07), "While people # elsewhere have long been talking of legislation to save daylight, # the city of Moose Jaw [Saskatchewan] has acted on its own hook." # DST in Moose Jaw began on Saturday, 1912-06-01 (no time mentioned: # presumably late evening, as below), and would run until "the end of # the summer". The discrepancy between municipal time and railroad # time was noted. # From Paul Eggert (2003-07-27): # Willett (1914-03) notes that DST "has been in operation ... in the # City of Moose Jaw, Saskatchewan, for one year." # From Paul Eggert (2006-03-22): # Shanks & Pottenger say that since 1970 this region has mostly been as Regina. # Some western towns (e.g. Swift Current) switched from MST/MDT to CST in 1972. # Other western towns (e.g. Lloydminster) are like Edmonton. # Matthews and Vincent (1998) write that Denare Beach and Creighton # are like Winnipeg, in violation of Saskatchewan law. # From W. Jones (1992-11-06): # The. . .below is based on information I got from our law library, the # provincial archives, and the provincial Community Services department. # A precise history would require digging through newspaper archives, and # since you didn't say what you wanted, I didn't bother. # # Saskatchewan is split by a time zone meridian (105W) and over the years # the boundary became pretty ragged as communities near it reevaluated # their affiliations in one direction or the other. In 1965 a provincial # referendum favoured legislating common time practices. # # On 15 April 1966 the Time Act (c. T-14, Revised Statutes of # Saskatchewan 1978) was proclaimed, and established that the eastern # part of Saskatchewan would use CST year round, that districts in # northwest Saskatchewan would by default follow CST but could opt to # follow Mountain Time rules (thus 1 hour difference in the winter and # zero in the summer), and that districts in southwest Saskatchewan would # by default follow MT but could opt to follow CST. # # It took a few years for the dust to settle (I know one story of a town # on one time zone having its school in another, such that a mom had to # serve her family lunch in two shifts), but presently it seems that only # a few towns on the border with Alberta (e.g. Lloydminster) follow MT # rules any more; all other districts appear to have used CST year round # since sometime in the 1960s. # From Chris Walton (2006-06-26): # The Saskatchewan time act which was last updated in 1996 is about 30 pages # long and rather painful to read. # http://www.qp.gov.sk.ca/documents/English/Statutes/Statutes/T14.pdf -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On 09/12/2015 08:42 PM, Ben Finney wrote: > Michael Torrie writes: >> On 09/12/2015 08:22 PM, Mark Lawrence wrote: >>> You appear to have the same level of knowledge of Python internals as >>> the RUE has of the Python 3.3+ FSR unicode implementation. Let's have >>> some fun, is Python pass by value or pass by reference? It has to be >>> more interesting debating that than the drivel that's gone before in >>> this thread. >> >> Oh you are a devious one there! This should get good. > > No, it should stop there. Taunting trolls is no more welcome here than > trolling. Ben, If the troll being taunted here is referring to me, I suggest you review my posts in this thread, You've said in the past that you don't read posts from Google Groups (that's fine, your choice) so perhaps you do not have a clear idea what I have written. One of the most effective ways for a community to discredit itself is to make accusations of trolling in response to unpopular but legitimate and reasonable opinion. -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Mon, Sep 14, 2015 at 1:31 AM, rurpy--- via Python-list wrote: > Ben, > > If the troll being taunted here is referring to me, I suggest > you review my posts in this thread, You've said in the past > that you don't read posts from Google Groups (that's fine, > your choice) so perhaps you do not have a clear idea what I > have written. I think Ben's referring to taunting jmf, whom Mark called the "RUE" or "Resident Unicode Expert". There has been a long-standing antagonism between those two (which is completely understandable), and one which often spills over into vitriolic posts (which is less acceptable). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
In a message of Sun, 13 Sep 2015 10:27:30 -0500, Tim Peters writes: >Hi, Laura! By "zoneinfo" here, we mean the IANA (aka "Olson") time >zone database, which is ubiquitous on (at least) Linux: > >https://www.iana.org/time-zones > >So "will a wrapping of zoneinfo handle XYZ?" isn't so much a question >about the wrapping as about what's in the IANA database. Then we had better be able to override it when it is wrong. >Best guess is that Creighton's rules are covered by that database's >America/Winnipeg entries. ># Saskatchewan ># Other western towns (e.g. Lloydminster) are like Edmonton. ># Matthews and Vincent (1998) write that Denare Beach and Creighton ># are like Winnipeg, in violation of Saskatchewan law. I think that this will work. Creighton is just across the border from Flin Flan, Manitoba. Indeed I think the problem of 'drunken people from Manitoba trying to get one hours more drinking done and being a menace on the highway' may have fueled the 'we are going to have DST in violation of the law' movement in Creighton. But I am not sure how it is that a poor soul who just wants to print a railway schedule 'in local time' is supposed to know that Creighton is using Winnipeg time. Laura -- https://mail.python.org/mailman/listinfo/python-list
Re: Phone Tree
Somewhere in there you may find that dictionary dispatching is
something worth doing. I don't know. This whole sort of problem
is sort of grating, in that it is trying to replicate one of the
most irritating user experiences on the planet ...
>From python3: Patterns, Recipes and Idioms
http://www.google.se/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&ved=0CEUQFjAEahUKEwiJv4CtxPTHAhVqvnIKHY68Bec&url=http%3A%2F%2Fpython-3-patterns-idioms-test.readthedocs.org%2Fen%2Flatest%2FMultipleDispatching.html&usg=AFQjCNG0UFOKpxJNVDSCt9dtAJ55SC_zEA
The guts of the thing is a simple dictionary:
outcome = {
(Paper, Rock): Outcome.WIN,
(Paper, Scissors): Outcome.LOSE,
(Paper, Paper): Outcome.DRAW,
(Scissors, Paper): Outcome.WIN,
(Scissors, Rock): Outcome.LOSE,
(Scissors, Scissors): Outcome.DRAW,
(Rock, Scissors): Outcome.WIN,
(Rock, Paper): Outcome.LOSE,
(Rock, Rock): Outcome.DRAW,
}
Which, in this case, plays the child's game rock, paper, scissors with
2 players. But you could use a tuple with 10 values.
If a lot of your outcomes are going to arrive at the same answer 'Stick
the device in a box, print off this shipping label, and send it via
UPS to our repair service centre.' then this approach will have more
appeal.
Sometimes what you want is to dispatch on a set of functions with
arguments, and you can stick that in your dictionary as well.
outcomes = { (a,c,d) : (function1_name, (arg1, arg2, arg3))
(a, b, d) : (function2_name, (arg1,))}
But whether this is going to help or not really depends on your data.
If you find yourself itching for a case statement, then it probably
will. But I am not sure that this was your intent in the first place.
Laura
--
https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
Random832 writes: > Akira Li <[email protected]> writes: >>Rustom Mody writes: >>> viz. I have two variables (or names!) say a and b which look the same >> a >>> [[1,2],[1,2]] >> b >>> [[1,2],[1,2]] >>> And yet doing >> a[0][0] = "Oops!" >>> gives a data structure one "Oops!" >>> whereas doing it to b mysteriously gives 2 >> >> Sorry, I haven't followed the whole thread. Could your provide a >> complete code example? Mention what you expect to happen and what >> happens instead in your case. > > a0 = a1 = [1, 2] > b0 = [1, 2] > b1 = [1, 2] > a = [a0, a1] > b = [b0, b1] > del a0, a1, b0, b1 > > There's nothing about *him* expecting anything wrong to happen. The > question is how to draw a diagram that unambiguously shows the resulting > structure using the "parcel tags" model shown in the diagrams (and > without having a0/a1/etc as actual names) I'm not sure what "parcel tags" model is but if you mean these pictures[1] than it works in this case as well as any other (take *a*, *b* nametags, put them on the corresponding balloons that represents list objects). The only names left are *a* and *b* that refer to the corresponding lists. There is no ambiguity there to put *a*, *b* nametags. Lists as any other containers contain references to other objects and therefore "box and arrows" model provides _more details_ here[2,3] > If the "parcel tags" model can't show it, then the "parcel tag" model > clearly is not a correct and complete depiction of how Python actually > works. > (If I were drawing a picture rather than ASCII I'd add something to make > it clear that the pairs shown are list objects Like, it's a circle with > the word "list" and two pointer-boxes inside it.) "correct and complete" is impossible in the general case for any model. Imagine what happens if numpy arrays are used instead of Python lists: lst = [numpy.array([1, 2]) for _ in range(3)] a = [lst[0], lst[0]] b = [lst[1], lst[2]] Note: there could be no a[0][0], a[0][1], etc corresponding Python objects until you explicitly reference them in the code. If there are no Python objects then you can't draw any arrows and therefore "box and arrows" model is incomplete. Or consider this collections of all Unicode characters: class U: def __len__(self): return sys.maxunicode + 1 def __getitem__(self, index): if index < 0: index += len(self) if 0 <= index < len(self): return chr(index) raise IndexError(index) u = U() print(u[0x61]) # -> a In this example, it is even more clear that the corresponding items might not exist until they are explicitly referenced in a program. *u* is a sequence as any other in Python (it is easy to make it *collections.abc.Sequence* compatible). Or this: lst = [range(1, 3) for _ in range(3)] a = [lst[0], lst[0]] b = [lst[1], lst[2]] In Python 2, it is the exact replica of the original example. In Python 3, it is the same if you don't need to mutate the ranges. Again, the leaf objects might not exist until you reference them in the code in Python 3. Finally, consider a Python sequence that uses os.urandom() internally. No model will predict the result (and therefore no model is complete) in this case. [1] http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#python-has-names [2] http://www.pythontutor.com/visualize.html#code=a0+%3D+a1+%3D+%5B1,+2%5D%0Ab0+%3D+%5B1,+2%5D%0Ab1+%3D+%5B1,+2%5D%0Aa+%3D+%5Ba0,+a1%5D%0Ab+%3D+%5Bb0,+b1%5D%0Adel+a0,+a1,+b0,+b1%0A&mode=display&origin=opt-frontend.js&cumulative=false&heapPrimitives=false&textReferences=false&py=3&rawInputLstJSON=%5B%5D&curInstr=6 [3] http://www.pythontutor.com/visualize.html#code=a0+%3D+a1+%3D+%5B1,+2%5D%0Ab0+%3D+%5B1,+2%5D%0Ab1+%3D+%5B1,+2%5D%0Aa+%3D+%5Ba0,+a1%5D%0Ab+%3D+%5Bb0,+b1%5D%0Adel+a0,+a1,+b0,+b1%0Aa%5B0%5D%5B0%5D+%3D+%22Oops!%22&mode=display&origin=opt-frontend.js&cumulative=false&heapPrimitives=false&textReferences=false&py=3&rawInputLstJSON=%5B%5D&curInstr=7 -- https://mail.python.org/mailman/listinfo/python-list
Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
Laura Creighton writes: > But I am not sure how it is that a poor soul who just wants to print a > railway schedule 'in local time' is supposed to know that Creighton is > using Winnipeg time. The same way they know that any other location is using whatever time it uses. By the user having specified it (if the user's local time is wrong they'll "obviously" know it as soon as the daylight saving transition is supposed to happen but doesn't) or by checking the location against the data at http://efele.net/maps/tz/canada/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Integration using scipy odeint
In a message of Sun, 13 Sep 2015 07:49:37 -0700, sagar k writes: >Dear all > >I'm using Python 3.4.3. I am facing a problem in integrating using odeint >solver. In the following code, tran is a function and in those are the >variables which are arrays. These variables change their values with respect >to time (the time which I pass to the function). I tried defining a loop >inside the function, but Python throws an error saying float object not >iterable. Please guide me how to solve this problem. > >#initial is an array containing initial values for the integration, dt is the >time array with unequal time steps, which I have captured from other part of >the code > >def tran(initial,dt): >for i in dt: >k1 [i] = 2.8e8 * math.exp(-21100/ta[i]) # k1,k2,k3 & k4 are constants > which change according to temperature (ta), which in turn changes with > respect to time. >k2 [i] = 1.4e2 * math.exp(-12100/ta[i]) # ta changes its values > according to dt, which is array. It runs from 0-6 with unequal time steps. >k3 [i] = 1.4e5 * ta[i] * math.exp(-19680/ta[i]) # I've captured dt and > all other arrays here from another loop, which is not of importtance. >k4 [i] = 1.484e3 * ta[i] >y = initial[0] >z = initial[1] >dn = (6*rho*initial[1]) >dd = (math.pi*2000*initial[0]) >ds = (dn/dd)**1/3 >dydt = (166.2072*ta[i]*cca[i] - (1.447e13 * ta[i]**0.5 * rho**1/6 * > y**1/6 * rho**1/6 * z**1/6 * 0.0832)) # cca,ta are arrays. y & z are 2 > dependent variables >dzdt = (k1[i]*ta[i]*cca[i]*12.011 + (21.2834*k2[i]*ta[i]*cca[i] * > y**1/2 *ds) - (k3[i]*ta[i]*12.011*y*math.pi*ds**2 * cco[i]) - >(phi*k4[i]*ta[i]*xo[i]*12.011*y*math.pi*ds**2)) >return [dydt,dzdt] # dydt & dzdt are my final time integrated values > >initial = [0.01,1e-5] >sol = odeint(tran, initial, dt) #this is my function call > >If I pass array in my function call, it says only length-1 can be converted to >Python scalars. > >So I request all the experts in the group to tell me where I'm going wrong. > >Regards You are getting this error, correct? TypeError: only length-1 arrays can be converted to Python scalars I don't know anything about odeint. But when I get these errors it is because I passed a numpy array into something that wanted a python list. This may be what you are doing. numpy arrays have a tolist method. see if passing array.tolist() instead of array works for you. Laura -- https://mail.python.org/mailman/listinfo/python-list
Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
[Tim] >> Hi, Laura! By "zoneinfo" here, we mean the IANA (aka "Olson") time >> zone database, which is ubiquitous on (at least) Linux: >> >>https://www.iana.org/time-zones >> >>So "will a wrapping of zoneinfo handle XYZ?" isn't so much a question >>about the wrapping as about what's in the IANA database. [Laura] > Then we had better be able to override it when it is wrong. Anyone can write their own tzinfo implementing any rules they like, and nobody is required to use anyone else's tzinfos. That said, zoneinfo is the most extensive collection of time zone info there is, so most people will probably use only that. And that said, zoneinfo is inordinately concerned with recording highly dubious guesses about what "the rules" were even over a century ago. Most people would probably be happy with a tzinfo that _only_ knew what "today's rules" are. POSIX TZ rules give a simple way to spell exactly that. Simple, but annoyingly cryptic. Gustavo's `dateutil` already supplies a way to magically build a tzinfo implementing a zone specified by a POSIX TZ rule string. More obvious ways to spell that are surely possible (like, for example, the obvious ways). Patches welcome ;-) >> Best guess is that Creighton's rules are covered by that database's >> America/Winnipeg entries. >> >> # Saskatchewan >> # Other western towns (e.g. Lloydminster) are like Edmonton. >> # Matthews and Vincent (1998) write that Denare Beach and Creighton >> # are like Winnipeg, in violation of Saskatchewan law. > I think that this will work. > Creighton is just across the border from Flin Flan, Manitoba. Indeed I think > the problem of 'drunken people from Manitoba trying to get one hours more > drinking done and being a menace on the highway' may have fueled the > 'we are going to have DST in violation of the law' movement in Creighton. :-) > But I am not sure how it is that a poor soul who just wants to print a > railway schedule 'in local time' is supposed to know that Creighton is > using Winnipeg time. I'm not sure how that poor soul would get a railway schedule manipulable in Python to begin with ;-) If it's "a problem" for "enough" users of a computer system, a Linux admin could simply make "America/Creighton" a link to the "America/Winnipeg" tzfile. But doing that for every nameable place on Earth might be considered annoying. To cover everyone, you may even need to specify a street address within "a city": http://www.quora.com/Are-there-any-major-cities-divided-by-two-time-zones Blame politicians for this. I can assure you Guido is not responsible for creating this mess ;-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Mon, Sep 14, 2015 at 4:04 AM, Akira Li <[email protected]> wrote: >> (If I were drawing a picture rather than ASCII I'd add something to make >> it clear that the pairs shown are list objects Like, it's a circle with >> the word "list" and two pointer-boxes inside it.) > > "correct and complete" is impossible in the general case for any model. > > Imagine what happens if numpy arrays are used instead of Python lists: > > lst = [numpy.array([1, 2]) for _ in range(3)] > a = [lst[0], lst[0]] > b = [lst[1], lst[2]] > > Note: there could be no a[0][0], a[0][1], etc corresponding Python > objects until you explicitly reference them in the code. If there are no > Python objects then you can't draw any arrows and therefore "box and > arrows" model is incomplete. > > Or consider this collections of all Unicode characters: > > class U: > def __len__(self): > return sys.maxunicode + 1 > def __getitem__(self, index): > if index < 0: > index += len(self) > if 0 <= index < len(self): > return chr(index) > raise IndexError(index) > > u = U() > print(u[0x61]) # -> a > > In this example, it is even more clear that the corresponding items > might not exist until they are explicitly referenced in a program. What you've shown there is that it's perfectly possible to have an abstract collection which generates objects as they're needed. In the same way, you could define an infinite range object, which effectively has all positive odd numbers in it: class Odd: def __getitem__(self, index): if index >= 0: return index * 2 + 1 raise IndexError(index) Obviously it can't have objects representing every positive odd number, because that's an infinite set. If you want to think of this as containing all of those integers, sure, but now we're getting into functional programming styles and ways of representing infinity in finite RAM, and some things will look a bit different. However, none of this has anything to do with Python's object model. The expression "index * 2 + 1" results in the creation of new integer objects as required, rather than simply retrieving them from some containment list. The boxes-and-arrows stuff is all about pre-existing objects; if I construct one list from another, I expect all the references to be the same, but if I construct two Odd() objects, they don't have to be: >>> o1 = Odd(); x1 = o1[12345] >>> o2 = Odd(); x2 = o2[12345] >>> x1 is x2 False Even though every Odd() must, by definition, contain the exact same integers, it doesn't contain the same objects - it doesn't contain any objects. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
Akira Li <[email protected]> writes: > I'm not sure what "parcel tags" model is but if you mean these > pictures[1] than it works in this case as well as any other (take *a*, > *b* nametags, put them on the corresponding balloons that represents > list objects). > > The only names left are *a* and *b* that refer to the corresponding > lists. There is no ambiguity there to put *a*, *b* nametags. But how do you make an a[0][0]/a[1][0] nametag to put on the "1" object? > Lists as any other containers contain references to other objects and > therefore "box and arrows" model provides _more details_ here[2,3] Right, but why not use the *same* model to represent *namespaces*? It seems like the "tags" model only exists to make the incorrect claim that python doesn't have variables (the boxes are variables). >> If the "parcel tags" model can't show it, then the "parcel tag" model >> clearly is not a correct and complete depiction of how Python actually >> works. >> (If I were drawing a picture rather than ASCII I'd add something to make >> it clear that the pairs shown are list objects Like, it's a circle with >> the word "list" and two pointer-boxes inside it.) > > "correct and complete" is impossible in the general case for any > model. Everything you wrote here has the same issue: The "objects" you are talking about do not physically exist, but are simply the result of calling a method on the object. Therefore they do not *belong* on the diagram, and the diagram not showing them does not mean the diagram is not complete. -- https://mail.python.org/mailman/listinfo/python-list
Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
In a message of Sun, 13 Sep 2015 14:00:33 -0500, Tim Peters writes: >> But I am not sure how it is that a poor soul who just wants to print a >> railway schedule 'in local time' is supposed to know that Creighton is >> using Winnipeg time. > >I'm not sure how that poor soul would get a railway schedule >manipulable in Python to begin with ;-) Via Rail will give you a schedule when you book your tickets. But I am wrong, it gives it to you in local time, which you can scrape or even use the via rail api. So it is the person getting off in Creighton who wants to tell his relatives back in Halifax what time he is arriving (in their time) (so they can call him and avoid the hellish hotel surtax on long distance calls) who will have the problem. And this is the sort of use case I think we will see a lot of. >Blame politicians for this. I can assure you Guido is not responsible >for creating this mess ;-) :) Laura -- https://mail.python.org/mailman/listinfo/python-list
How to set the history commands visible ?
Hi guys, Today, a new python stable version was released (thanks for your job)... and I write to ask you for the recommended method to compile the sources (in Debian GNU/Linux platfom) in order to the arrow keys emit the history commands instead of... it seems that escape sequences... Python 3.5.0 (default, Sep 13 2015, 17:58:38) [GCC 4.9.2] on linux Type "help", "copyright", "credits" or "license" for more information. >>> ^[[A^[[A^[[B^[[B (I run the configure, make, make test & make install scripts) Furthermore, I'd like also to ask a simple additional questions: Is yet an automatic indentation system implemented ? How to activate them ? Glus -- https://mail.python.org/mailman/listinfo/python-list
Cannot create a virtualenv
Installing Py 3.5 and `pip install virtualenv` worked fine. However, I cannot create a virtualenv. "OSError: Command C:\ve\ve33\Scripts\python.exe -c "import sys, pip; sys...d\"] + sys.argv[1:]))" setuptools pip wheel failed with error code 1" Any suggestions? -- https://mail.python.org/mailman/listinfo/python-list
convert element in a list to float
For starters, I googled and saw a plethora of writings on how to convert an entire list from string to float. My interest is on select elements in the list. The output from the print statement: print scenarioList is as follows [ '300', '"N"', '1140', '"E"' ] I need to convert the first and third element to float. lat = ( float ) scenarioList [ 0 ] lon = ( float ) scenarioList [ 2 ] fails (invalid syntax). How can I achieve my objective. Thanks in advance -- https://mail.python.org/mailman/listinfo/python-list
Re: convert element in a list to float
On 13/09/2015 20:55, [email protected] wrote: For starters, I googled and saw a plethora of writings on how to convert an entire list from string to float. My interest is on select elements in the list. The output from the print statement: print scenarioList is as follows [ '300', '"N"', '1140', '"E"' ] I need to convert the first and third element to float. lat = ( float ) scenarioList [ 0 ] lon = ( float ) scenarioList [ 2 ] fails (invalid syntax). How can I achieve my objective. Thanks in advance Strong hint, you do not cast the strings to floats, you call the builtin float() function to do the conversion. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
[Laura] >>> But I am not sure how it is that a poor soul who just wants to print a >>> railway schedule 'in local time' is supposed to know that Creighton is >>> using Winnipeg time. [Tim] >> I'm not sure how that poor soul would get a railway schedule >> manipulable in Python to begin with ;-) [Laura] > Via Rail will give you a schedule when you book your tickets. But I > am wrong, it gives it to you in local time, which you can scrape or > even use the via rail api. So it is the person getting off in > Creighton who wants to tell his relatives back in Halifax what > time he is arriving (in their time) (so they can call him and > avoid the hellish hotel surtax on long distance calls) who will > have the problem. Whatever time zone the traveler's railroad schedule uses, so long as it sticks to just one the traveler subtracts the departure time from the arrival time to determine how long the trip takes. They add that to the Halifax time at which they depart, and tell their Halifax relatives the result. They don't need to know anything about the destination's time zone to do this, unless a daylight transition occurs between departure and arrival, and the schedule itself remembered to account for it. In which case, pragmatically, they can just add an hour "to be safe" ;-) > And this is the sort of use case I think we will see a lot of. But there's nothing new here: datetime has been around for a dozen years already, and nobody is proposing to add any new basic functionality to tzinfos. PEP 495 is only about adding a flag to allow correct conversion of ambiguous local times (typically at the end of DST, when the local clock repeats a span of times) to UTC. So if this were a popular use case, I expect we would already have heard of it. Note that Python zoneinfo wrappings are already available via, at least, the pytz and dateutil packages. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to set the history commands visible ?
In a message of Sun, 13 Sep 2015 19:15:19 +0200, Glus Xof writes: >Hi guys, > >Today, a new python stable version was released (thanks for your job)... >and I write to ask you for the recommended method to compile the sources >(in Debian GNU/Linux platfom) in order to the arrow keys emit the history >commands instead of... it seems that escape sequences... > >Python 3.5.0 (default, Sep 13 2015, 17:58:38) >[GCC 4.9.2] on linux >Type "help", "copyright", "credits" or "license" for more information. ^[[A^[[A^[[B^[[B > >(I run the configure, make, make test & make install scripts) It seems your python is not installed with readline support, if the arrow keys are not working. You don't need to recompile python for this. Instead you need to install this. https://pypi.python.org/pypi/readline But I am surprised that you need this, as my debian linux unstable system has this out of the box, more or less always. I think this is because I have this package installed https://packages.debian.org/stretch/readline-common (there are versions for testing and stable as well). If I were you I would install this first and see if your arrow problems go away. If not, get out pip. >Furthermore, I'd like also to ask a simple additional questions: > >Is yet an automatic indentation system implemented ? >How to activate them ? I am not sure what you mean by this. If you, as I, was unhappy as anything about tab in the interactive console (at the far margin) meaning 'tab complete every builtin on the planet' rather than 'I'd like another level of indent please' -- then, 3.5, you are good to go. :) tabs typed flush to the margin just indent. tabs complete if you type them in the middle of an identifier. If you mean something else, then, well, explain it a little more, ok? >Glus Laura -- https://mail.python.org/mailman/listinfo/python-list
Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
In a message of Sun, 13 Sep 2015 15:13:53 -0500, Tim Peters writes: >[Laura] >> Via Rail will give you a schedule when you book your tickets. But I >> am wrong, it gives it to you in local time, which you can scrape or >> even use the via rail api. So it is the person getting off in >> Creighton who wants to tell his relatives back in Halifax what >> time he is arriving (in their time) (so they can call him and >> avoid the hellish hotel surtax on long distance calls) who will >> have the problem. > >Whatever time zone the traveler's railroad schedule uses, so long as >it sticks to just one This is what does not happen. Which is why I have written a python app to perform conversions for my parents, in the past. >But there's nothing new here: datetime has been around for a dozen >years already, and nobody is proposing to add any new basic >functionality to tzinfos. PEP 495 is only about adding a flag to >allow correct conversion of ambiguous local times (typically at the >end of DST, when the local clock repeats a span of times) to UTC. So >if this were a popular use case, I expect we would already have heard >of it. Note that Python zoneinfo wrappings are already available via, >at least, the pytz and dateutil packages. I am a happy user of pytz. On the other hand, I think this means that my brain has gone through some sort of non-reversible transformation which makes me accurate, but not exactly sane on the issue. I think I have misunderstood Alexander Belopolsky as saying that datetime had functionality which I don't think it has. Thus I thought we must be planning to add some functionality here. Sorry about this. However, people do need to be aware, if they are not already, that people with 3 times in 3 different tz will want to sort them. Telling them that they must convert them to UTC before they do so is, in my opinion, a very fine idea. Expecting them to work this out by themselves via a assertion that the comparison operator is not transitive, is, I think, asking a lot of them. Laura -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
Chris Angelico writes: > I think Ben's referring to taunting jmf, whom Mark called the "RUE" or > "Resident Unicode Expert". There has been a long-standing antagonism > between those two (which is completely understandable), and one which > often spills over into vitriolic posts (which is less acceptable). Chris has it right. What's especially unacceptable is invoking that person for amusement, irrelevant to the conversation. It's one thing to respond when a person comes into a thread to troll unbidden; it is quite another to taunt them unprompted. -- \ “I call him Governor Bush because that's the only political | `\ office he's ever held legally.” —George Carlin, 2008 | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: convert element in a list to float
In a message of Sun, 13 Sep 2015 12:55:13 -0700, [email protected] writes: > > >For starters, I googled and saw a plethora of writings on how to convert an >entire list from string to float. My interest is on select elements in the >list. The output from the print statement: print scenarioList > >is as follows > >[ '300', '"N"', '1140', '"E"' ] > >I need to convert the first and third element to float. > lat = ( float ) scenarioList [ 0 ] > lon = ( float ) scenarioList [ 2 ] > >fails (invalid syntax). How can I achieve my objective. > >Thanks in advance Does this help? >>> l = [ '300', '"N"', '1140', '"E"' ] >>> [float(l[0]), l[1], float(l[2]), l[3]] [300.0, '"N"', 1140.0, '"E"'] Laura -- https://mail.python.org/mailman/listinfo/python-list
Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
[Tim]
>> Whatever time zone the traveler's railroad schedule uses, so long as
>> it sticks to just one
[Laura]
> This is what does not happen. Which is why I have written a python
> app to perform conversions for my parents, in the past.
So how did they get the right time zone rules for Creighton?
>>But there's nothing new here: datetime has been around for a dozen
>>years already, and nobody is proposing to add any new basic
>>functionality to tzinfos. PEP 495 is only about adding a flag to
>>allow correct conversion of ambiguous local times (typically at the
>>end of DST, when the local clock repeats a span of times) to UTC. So
>>if this were a popular use case, I expect we would already have heard
>>of it. Note that Python zoneinfo wrappings are already available via,
>>at least, the pytz and dateutil packages.
> I am a happy user of pytz. On the other hand, I think this means that
> my brain has gone through some sort of non-reversible transformation
> which makes me accurate, but not exactly sane on the issue.
pytz made some strange decisions, from the POV of datetime's intended
tzinfo design. But it also solved a problem datetime left hanging:
how to disambiguate ambiguous local times.
The _intended_ way to model zones with UTC offset transitions was via
what the docs call a "hybrid" tzinfo: a single object smart enough on
its own to figure out, e.g., whether a datetime's date and time are in
"daylight" or "standard" time. However, there's currently no way for
such a tzinfo to know whether an ambiguous local time is intended to
be the earlier or the later of repeated times. PEP 495 aims to plug
that hole.
pytz solves it by _never_ creating a hybrid tzinfo. It only uses
eternally-fixed-offset tzinfos. For example, for a conceptual zone
with two possible total UTC offsets (one for "daylight", one for
"standard"), there two distinct eternally-fixed-offset tzinfo objects
in pytz. Then an ambiguous time is resolved by _which_ specific
tzinfo object is attached. Typically the "daylight" tzinfo for the
first time a repeated local time appears, and the "standard" tzinfo
for its second appearance.
In return, you have to use .localize() and .normalize() at various
times, because pytz's tzinfo objects themselves are completely blind
to the possibility of the total UTC offset changing. .localize() and
.normalize() are needed to possibly _replace_ the tzinfo object in
use, depending on the then-current date and time.
OTOH, `dateutil` does create hybrid tzinfo objects. No dances are
ever needed to possibly replace them. But it's impossible for
dateutil's tzinfos to disambiguate times in a fold. Incidentally,
dateutil also makes no attempt to account for transitions other than
DST (e.g., sometimes a zone may change its _base_ ("standard") offset
from UTC).
So, yup, if you're thoroughly indoctrinated in pytz behavior, you will
be accurate but appear insane to Guido ;-) At a semantic level, a
pytz tzinfo doesn't capture the notion of a zone with offset changes -
it doesn't even try to. All knowledge about offset changes is inside
the .localize() and .normalize() dances.
> I think I have misunderstood Alexander Belopolsky as saying that
> datetime had functionality which I don't think it has. Thus I thought
> we must be planning to add some functionality here. Sorry about this.
Guido told Alex to stop saying that ;-) You can already get
eternally-fixed-offset classes, like pytz does, on (at least) Linux
systems by setting os.environ['TZ'] and then exploiting that
.astimezone() without an argument magically synthesizes an
eternally-fixed-offset tzinfo for "the system zone" (which the TZ
envar specifies) current total UTC offset. That's not really
comparable to what pytz does, except at a level that makes a lot of
sense in theory but not much at all in practice ;-)
> However, people do need to be aware, if they are not already, that
> people with 3 times in 3 different tz will want to sort them. Telling
> them that they must convert them to UTC before they do so is, in my
> opinion, a very fine idea. Expecting them to work this out by themselves
> via a assertion that the comparison operator is not transitive, is,
> I think, asking a lot of them.
Of course. Note that it's _not_ a problem in pytz, though: there are
no sorting (or transitivity) problems if the only tzinfos you ever use
have eternally fixed UTC offsets. There are no gaps or folds then,
and everything works in an utterly obvious way - except that you have
to keep _replacing_ tzinfos when they become inappropriate for the
current dates and times in the datetimes they're attached to.
--
https://mail.python.org/mailman/listinfo/python-list
Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
On Sun, Sep 13, 2015 at 5:24 AM, Laura Creighton wrote: > My question, is whether it will handle Creighton, Saskatchewan, Canada? > Creighton is an odd little place. Like all of Saskatchewan, it is > in the Central time zone, even though you would expect it to be > in the Mountain time zone based on its location on the globe. > The people of Saskatchewan have decided not to adopt Daylight > Savings time. Except for the people of Creighton (and > nearby Denare Beach) -- who _do_ observe Daylight savings time. > > makes for an interesting corner case, one that I remember for > personal (and not economic, or professional) reasons. > Hi Laura! Wouldn't it be sufficient for people in Creighton to set their timezone to US/Central? IIUC the Canadian DST rules are the same as the US ones. Now, the question may remain how do people know what to set their timezone to. But neither pytz nor datetime can help with that -- it is up to the sysadmin. -- --Guido van Rossum (python.org/~guido) -- https://mail.python.org/mailman/listinfo/python-list
Re: Can't use Python Launcher on Windows after update to 3.5
On 10/09/2015 16:56, Mark Lawrence wrote: On 10/09/2015 11:20, Tim Golden wrote: On 10/09/2015 00:52, Mark Lawrence wrote: I've installed 3.5 for all users so it's in C:\Program Files From https://docs.python.org/3.5/using/windows.html#from-the-command-line it says "System-wide installations of Python 3.3 and later will put the launcher on your PATH. The launcher is compatible with all available versions of Python, so it does not matter which version is installed. To check that the launcher is available, execute the following command in Command Prompt:", but:- C:\Users\Mark\Documents\MyPython>py -3.4 'py' is not recognized as an internal or external command, operable program or batch file. Further running ftype shows nothing for Python, assoc just gives this .pyproj=VisualStudio.Launcher.pyproj.14.0. Surely this is wrong? Before I go to the bug tracker to raise an issue could somebody please confirm what I'm seeing, thanks. Well I've just installed 64-bit 3.5.0rc4 via the web installer (ie this: https://www.python.org/ftp/python/3.5.0/python-3.5.0rc4-amd64-webinstall.exe) onto a machine with 64-bit 3.4.2 already installed. I went for the default install. It all seems to be ok and py -3.4 --version gives me "Python 3.4.2" as expected. assoc/ftype both look ok. c:\windows\py.exe has the versions & dates I expect. TJG So I ran the 64-bit 3.5.0rc4 via the web installer and still no joy. Ran repair with same and it's business as usual. I'm not that bothered, it's here for the record should anybody else come searching, so chalk it up to experience and move on. Thanks anyway :) Exactly the same thing happened when I upgraded to 3.5.0. so raised http://bugs.python.org/issue25089 just in case it hurts other people more than it hurts me. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Auto indents (was Re: How to set the history commands visible ?)
On 9/13/2015 1:15 PM, Glus Xof wrote:
Is yet an automatic indentation system implemented ?
The Idle editor does pep8-aware 'smart indenting'. In the following,
'|' indicates the cursor position after is pressed.
A ':' at the end of the line adds 1 indent -- unless there is an opener
that has not been closed. So what looks like a buggy indent usually
indicates a syntax error in the user code.
a = 3
|
if a == 3:
|pass
a = int(len({})
|) # pep 8 positioning
a = int(
|) # pep 8 positioning
if a = 3:
if b = 5:
|pass
if a == int(len({}):
| # unclosed int(
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
Random832 writes: > Akira Li <[email protected]> writes: >> I'm not sure what "parcel tags" model is but if you mean these >> pictures[1] than it works in this case as well as any other (take *a*, >> *b* nametags, put them on the corresponding balloons that represents >> list objects). >> >> The only names left are *a* and *b* that refer to the corresponding >> lists. There is no ambiguity there to put *a*, *b* nametags. > > But how do you make an a[0][0]/a[1][0] nametag to put on the "1" object? a[0][0]/a[1][0] are not names. Though if we want to talk about the corresponding objects then a[0][0]/a[1][0] could be used instead of names (as a way to identify them). >> Lists as any other containers contain references to other objects and >> therefore "box and arrows" model provides _more details_ here[2,3] > > Right, but why not use the *same* model to represent *namespaces*? If it works for your case; use it. The links [2,3] show that It does work in this case (if it is correct to call what they show "box and arrows" model). > It seems like the "tags" model only exists to make the incorrect claim > that python doesn't have variables (the boxes are variables). If you mean this quote from [1]: Although we commonly refer to "variables" even in Python (because it's common terminology), we really mean "names" or "identifiers". In Python, "variables" are nametags for values, not labelled boxes. then *name* is the term that is defined in the Python language reference. The word "variable" we can use in day-to-day programming _unless_ we are discussing issues that are specific to _naming and binding_. In that case, we should use the _exact_ terminology. Otherwise there is nothing wrong with using "variables" casually in Python. Notice: that [2,3] model is different from "labelled boxes" model. There are arrows from *a*/*b* _to_ list objects i.e., *a*/*b* are not boxes that _contain_ list objects within -- _otherwise you have to put the *same* list into two *different* boxes_ -- let's not investigate quantum paradoxes here. The only difference from "parcel tags" model is that list items do not have explicit names. >>> If the "parcel tags" model can't show it, then the "parcel tag" model >>> clearly is not a correct and complete depiction of how Python actually >>> works. >>> (If I were drawing a picture rather than ASCII I'd add something to make >>> it clear that the pairs shown are list objects Like, it's a circle with >>> the word "list" and two pointer-boxes inside it.) >> >> "correct and complete" is impossible in the general case for any >> model. > > Everything you wrote here has the same issue: The "objects" you are > talking about do not physically exist, but are simply the result of > calling a method on the object. Therefore they do not *belong* on the > diagram, and the diagram not showing them does not mean the diagram is > not complete. "do not physically exist" does not make sense. Objects are *never* destroyed explicitly in Python (you can only make them *unreachable*). You can disable garbage collection completely and it is still will be Python. Immutable objects can be considered immortal e.g.: (1+1) -- question: does the object that represents int(2) exist before the expression is evaluated? The correct answer: it does not matter: int(2) can be created on the fly, a cached int(2) can be reused by a specific implementation -- Python doesn't care. I don't see why the model that can't describe range(1) in Python 3 pretends to be complete. [1] http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#python-has-names [2] http://www.pythontutor.com/visualize.html#code=a0+%3D+a1+%3D+%5B1,+2%5D%0Ab0+%3D+%5B1,+2%5D%0Ab1+%3D+%5B1,+2%5D%0Aa+%3D+%5Ba0,+a1%5D%0Ab+%3D+%5Bb0,+b1%5D%0Adel+a0,+a1,+b0,+b1%0A&mode=display&origin=opt-frontend.js&cumulative=false&heapPrimitives=false&textReferences=false&py=3&rawInputLstJSON=%5B%5D&curInstr=6 [3] http://www.pythontutor.com/visualize.html#code=a0+%3D+a1+%3D+%5B1,+2%5D%0Ab0+%3D+%5B1,+2%5D%0Ab1+%3D+%5B1,+2%5D%0Aa+%3D+%5Ba0,+a1%5D%0Ab+%3D+%5Bb0,+b1%5D%0Adel+a0,+a1,+b0,+b1%0Aa%5B0%5D%5B0%5D+%3D+%22Oops!%22&mode=display&origin=opt-frontend.js&cumulative=false&heapPrimitives=false&textReferences=false&py=3&rawInputLstJSON=%5B%5D&curInstr=7 -- https://mail.python.org/mailman/listinfo/python-list
Re: convert element in a list to float
On Sun, 13 Sep 2015 23:02:55 +0200, Laura Creighton wrote: > In a message of Sun, 13 Sep 2015 12:55:13 -0700, [email protected] > writes: >> >>For starters, I googled and saw a plethora of writings on how to convert >>an entire list from string to float. My interest is on select elements >>in the list. The output from the print statement: print scenarioList >> >>is as follows >> >>[ '300', '"N"', '1140', '"E"' ] >> >>I need to convert the first and third element to float. >> lat = ( float ) scenarioList [ 0 ] >> lon = ( float ) scenarioList [ 2 ] >> >>fails (invalid syntax). How can I achieve my objective. >> >>Thanks in advance > > Does this help? > l = [ '300', '"N"', '1140', '"E"' ] [float(l[0]), l[1], float(l[2]), l[3]] > [300.0, '"N"', 1140.0, '"E"'] Here's a method that will convert any value in a list that can be made a float into a float, and (I think) should leave all others as they are. It users a helper function and a list comprehension. >>> def tofloat(x): ... try: ... return float(x) ... except ValueError: ... return None ... >>> l = [ '300', '"N"', '1140', '"E"' ] >>> l = [ tofloat(x) or x for x in l ] >>> l [300.0, '"N"', 1140.0, '"E"'] -- Denis McMahon, [email protected] -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Mon, Sep 14, 2015 at 9:17 AM, Akira Li <[email protected]> wrote: > If you mean this quote from [1]: > > Although we commonly refer to "variables" even in Python (because it's > common terminology), we really mean "names" or "identifiers". In > Python, "variables" are nametags for values, not labelled boxes. > > then *name* is the term that is defined in the Python language > reference. The word "variable" we can use in day-to-day programming > _unless_ we are discussing issues that are specific to _naming and > binding_. In that case, we should use the _exact_ > terminology. Otherwise there is nothing wrong with using "variables" > casually in Python. Since you're talking about precise terminology, I think it would be better to say "name binding", rather than "naming and binding". When you talk of naming something (or someone!), you generally mean that it's possible to go from the thing to the (canonical) name. With people, for instance, you can walk up to someone and say "Hi! What's your name?", but with Python objects, you fundamentally can't. >> Everything you wrote here has the same issue: The "objects" you are >> talking about do not physically exist, but are simply the result of >> calling a method on the object. Therefore they do not *belong* on the >> diagram, and the diagram not showing them does not mean the diagram is >> not complete. > > "do not physically exist" does not make sense. Objects are *never* > destroyed explicitly in Python (you can only make them > *unreachable*). You can disable garbage collection completely and it is > still will be Python. Immutable objects can be considered immortal e.g.: > > (1+1) -- question: does the object that represents int(2) exist before > the expression is evaluated? > > The correct answer: it does not matter: int(2) can be created on the > fly, a cached int(2) can be reused by a specific implementation -- > Python doesn't care. > > I don't see why the model that can't describe range(1) in Python 3 > pretends to be complete. "Physically" isn't really the right word for it, given that objects in Python code aren't physical and therefore don't *ever* "physically exist". My bad there. But the objects completely do not exist. Yes, with integers you can't tell... but what about here? dependencies = collections.defaultdict(list) for fn in files: for dep in gather_deps(fn): dependencies[dep].append(fn) Until the moment when dependencies[dep] is requested for some new value of dep, the list *does not exist*. It is constructed anew. Obviously the end result of this is a dict of lists, and since those lists aren't accessible from anywhere else, it makes fine sense to talk about those lists as being "contained within" the (default)dict; but they clearly didn't exist until they were poked at. They're Heisenburg's Lists, I guess... ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Phone Tree
On Sun, 13 Sep 2015 07:39:23 -0700, Azureaus wrote:
> Does anyone have any ideas for a more elegant solution? My thoughts are
> that I could use a tree data structure and hence make traversing the
> tree recursive based on yes or no answers. I'm happy to put the time in
> to explain these more complex ideas, I'm just hoping those with more
> expertise than myself could either help verify the idea or suggest
> alternatives.
The trick is to separate the data and the processing.
Each question has a yes, no answer, so start with a dictionary of data
tuples (you could use a list, but using a dictionary makes the
relationship slightly easier to walk through):
questions = {
1: (q1, response if yes, response if no),
2: (q2, response if yes, response if no) }
The responses can be either a number of another question, or a result
text.
Then your algorithm is broadly:
x = 1:
while x is numeric:
ask questions[x][0]
if answer is "yes":
x = questions[x][1]
if answer is "no":
x = questions[x][2]
answer is x
You can use a list instead of a dictionary, just remember 0 indexing when
you're working out which question leads to which next question.
This way also makes for an interesting talking point about separating
data and code, especially given the multiple if statements issue.
--
Denis McMahon, [email protected]
--
https://mail.python.org/mailman/listinfo/python-list
Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
[Guido]
> Wouldn't it be sufficient for people in Creighton to set their timezone to
> US/Central? IIUC the Canadian DST rules are the same as the US ones. Now,
> the question may remain how do people know what to set their timezone to.
> But neither pytz nor datetime can help with that -- it is up to the
> sysadmin.
As Laura's use case evolved, it seems it was more that a train
traveler from Halifax to Creighton wants to tell their Halifax
relatives when they'll arrive in Creighton, but (of course) expressed
in Halifax time. Nobody in this case knows anything about Creighton's
rules, except the traveler may be staring at a train schedule giving
arrival in Creighton time anyway.
While this may be beyond pytz's wizardy, nothing is too hard for datetime ;-)
datetime.timezone.setcontext("datetime-sig messages from mid-Sep 2015")
arrivaltime = datetime.strptime(scraped_arrival_time, "")
arrivaltime = datetime.replace(arrivaltime,
tzinfo=gettz("Context/Creighton"))
print(arrivaltime.astimezone(gettz("Context/Halifax"))
--
https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
Chris Angelico writes: > On Mon, Sep 14, 2015 at 9:17 AM, Akira Li <[email protected]> wrote: >> If you mean this quote from [1]: >> >> Although we commonly refer to "variables" even in Python (because it's >> common terminology), we really mean "names" or "identifiers". In >> Python, "variables" are nametags for values, not labelled boxes. >> >> then *name* is the term that is defined in the Python language >> reference. The word "variable" we can use in day-to-day programming >> _unless_ we are discussing issues that are specific to _naming and >> binding_. In that case, we should use the _exact_ >> terminology. Otherwise there is nothing wrong with using "variables" >> casually in Python. > > Since you're talking about precise terminology, I think it would be > better to say "name binding", rather than "naming and binding". When > you talk of naming something (or someone!), you generally mean that > it's possible to go from the thing to the (canonical) name. With > people, for instance, you can walk up to someone and say "Hi! What's > your name?", but with Python objects, you fundamentally can't. "Naming and binding" is the title from the Python language reference https://docs.python.org/3/reference/executionmodel.html#naming-and-binding Otherwise, I agree with you ("name" is better here). >>> Everything you wrote here has the same issue: The "objects" you are >>> talking about do not physically exist, but are simply the result of >>> calling a method on the object. Therefore they do not *belong* on the >>> diagram, and the diagram not showing them does not mean the diagram is >>> not complete. >> >> "do not physically exist" does not make sense. Objects are *never* >> destroyed explicitly in Python (you can only make them >> *unreachable*). You can disable garbage collection completely and it is >> still will be Python. Immutable objects can be considered immortal e.g.: >> >> (1+1) -- question: does the object that represents int(2) exist before >> the expression is evaluated? >> >> The correct answer: it does not matter: int(2) can be created on the >> fly, a cached int(2) can be reused by a specific implementation -- >> Python doesn't care. >> >> I don't see why the model that can't describe range(1) in Python 3 >> pretends to be complete. > > "Physically" isn't really the right word for it, given that objects in > Python code aren't physical and therefore don't *ever* "physically > exist". My bad there. > > But the objects completely do not exist. Yes, with integers you can't > tell... but what about here? > > dependencies = collections.defaultdict(list) > for fn in files: > for dep in gather_deps(fn): > dependencies[dep].append(fn) > > Until the moment when dependencies[dep] is requested for some new > value of dep, the list *does not exist*. It is constructed anew. > Obviously the end result of this is a dict of lists, and since those > lists aren't accessible from anywhere else, it makes fine sense to > talk about those lists as being "contained within" the (default)dict; > but they clearly didn't exist until they were poked at. They're > Heisenburg's Lists, I guess... lists are _mutable_ in Python. -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Mon, Sep 14, 2015 at 10:30 AM, Akira Li <[email protected]> wrote: > "Naming and binding" is the title from the Python language reference > https://docs.python.org/3/reference/executionmodel.html#naming-and-binding > > Otherwise, I agree with you ("name" is better here). Ah, gotcha. That's talking in much broader scope, so "naming" makes a bit more sense there. In any case, I can't think of a better term for it in the full context. >> Until the moment when dependencies[dep] is requested for some new >> value of dep, the list *does not exist*. It is constructed anew. >> Obviously the end result of this is a dict of lists, and since those >> lists aren't accessible from anywhere else, it makes fine sense to >> talk about those lists as being "contained within" the (default)dict; >> but they clearly didn't exist until they were poked at. They're >> Heisenburg's Lists, I guess... > > lists are _mutable_ in Python. So? Objects are objects. Some of them have no means of changing their values, while others do. But the Python object model is absolutely the same for all of them; it's not "pass by value for immutables, pass by reference for mutables" as some have tried to claim. Immutable objects have values and identities; the only difference is that the compiler is allowed to constant-fold, using the same string "hello" in each of the three places where such a string comes up, or sharing the tuple (1,2,None) across usages. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: convert element in a list to float
Hi Forums_MP and welcome, On Mon, 14 Sep 2015 05:55 am, [email protected] wrote: > For starters, I googled and saw a plethora of writings on how to convert > an entire list from string to float. My interest is on select elements > in the list. The output from the print statement: print scenarioList > > is as follows > > [ '300', '"N"', '1140', '"E"' ] > > I need to convert the first and third element to float. > lat = ( float ) scenarioList [ 0 ] > lon = ( float ) scenarioList [ 2 ] > > fails (invalid syntax). How can I achieve my objective. By now you have hopefully discovered that the answer is to call float as a function: lat = float(scenarioList[0]) but I wonder what in the documentation or examples you saw suggested to you that Python used the C type-cast syntax `(float)value`? Whatever it was that gave you this wrong impression needs to be fixed. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Mon, 14 Sep 2015 09:17 am, Akira Li wrote: > I don't see why the model that can't describe range(1) in Python 3 > pretends to be complete. Please explain. range(1) returns a range instance. What is hard about that? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Sunday, September 13, 2015 at 2:49:13 PM UTC-6, Ben Finney wrote: > Chris Angelico writes: > > > I think Ben's referring to taunting jmf, whom Mark called the "RUE" or > > "Resident Unicode Expert". There has been a long-standing antagonism > > between those two (which is completely understandable), and one which > > often spills over into vitriolic posts (which is less acceptable). > > Chris has it right. > > What's especially unacceptable is invoking that person for amusement, > irrelevant to the conversation. It's one thing to respond when a person > comes into a thread to troll unbidden; it is quite another to taunt them > unprompted. Thank you for making that clear. -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
Steven D'Aprano writes: > On Mon, 14 Sep 2015 09:17 am, Akira Li wrote: > >> I don't see why the model that can't describe range(1) in Python 3 >> pretends to be complete. > > > Please explain. > > range(1) returns a range instance. What is hard about that? Look at the last example: http://thread.gmane.org/gmane.comp.python.general/782626/focus=782704 -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Mon, Sep 14, 2015 at 11:22 AM, Akira Li <[email protected]> wrote: > Steven D'Aprano writes: > >> On Mon, 14 Sep 2015 09:17 am, Akira Li wrote: >> >>> I don't see why the model that can't describe range(1) in Python 3 >>> pretends to be complete. >> >> >> Please explain. >> >> range(1) returns a range instance. What is hard about that? > > Look at the last example: > http://thread.gmane.org/gmane.comp.python.general/782626/focus=782704 Still not sure what the problem is. As per Python's object model, the lists contain references to range objects. a contains two references to the same range object, b contains references to each of two distinct range objects. What of it? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On 09/13/2015 06:50 AM, Steven D'Aprano wrote: > On Sun, 13 Sep 2015 04:45 am, [email protected] wrote: >> On 09/12/2015 10:32 AM, Steven D'Aprano wrote: >>> On Sat, 12 Sep 2015 02:42 pm, Random832 wrote: >>> [...] >>> Computer science and IT is *dominated* by a single usage for "pointer" -- >>> it's an abstract memory address. The fundamental characteristics of >>> pointers are: >> >> Just upthread, you claimed something was "universally agreed" > > I did? "Universially agreed" doesn't sound like something I would say. Do > you have a link to where I said that? > I think you're confusing me with somebody else. Somebody who is not me. I should have copy/pasted rather than paraphrasing from memory. You said "near-universal agreement" ("Re: Python handles globals badly", 2015-09-10). The difference does not change my response at all. > [...] > I have little problem with you using "pointer" as a metaphor: "Python > variables are like pointers in these ways...". I do have a problem with you > insisting that they are pointers. First, I am very cautious about about using absolute and dogmatic words like *are* [pointers] (although I probably have occasionally for brevity or in response to someones else's dogmatism.) If you go back over what I've written, I think you'll see that my main point is that describing what is in python "variables" and objects as pointers can be useful in some circumstances as an alternative to the current official description (with people who have had some experience with pointers in other languages, for example). The "standard definition" you keep referring to (and basing your arguments on was): An address, from the point of view of a programming language.[...] Wikipedia also seems to define pointer in terms of memory address. As I said, I think when describing the behavior of a language in abstract terms it is perfectly valid to take "address" equally abstractly (eg a token that lets you retrieve the same data every time you use it) but unfortunately for me Wikipedia defines "address" as the conventional linear numbers used in real-world computers. And I am not going to waste my time trying to convince anyone that Wikipedia is wrong or the context in inappropriate. Wikipedia also makes a distinction between "pointer" as something that refers to some data by "memory address" and "reference" which refers to some data by any means (including but not limited to a memory address, eg offset from current address or url). That was not distinction I knew of; I considered both terms as being more or less synonymous (in the general sense, obviously they are different in specific domains like C++). So I will retract any claim I made about "pointer" being a technically correct term (because Python-the-language imposes no restrictions on on how references are implemented.) Nevertheless I'll continue to maintain that it is useful to explain how python works in terms of pointers in that: 1) The distinction between abstract pointers(*) and references is non-existant or irrelevant in Python for any existing implementation. 2) You can accurately specify python-the-language in term of abstract pointers (ie, "as if") regardless of how it is currently specified. 3) People who've used pointers in other languages are more easily able to grasp Python semantics when presented in term of pointers, a concept they already understand. (*) by "abstract pointers" I mean pointers in the sense given in your definition, not C datatype pointers. If you insist on "references" that's ok too, the description can be accompanied with a wink and a whispered, "hey, references are really like pointers".) Those are my opinions, if you have any clear counter examples I would certainly like to know of them but I've not seen or read anything yet that indicates they are wrong. Below I snipped out all your responses that were essentially "that's not the standard definition of pointers", having addressed those above. > [...] >> It may not be appropriate way to describe Python for everybody but >> it is perfectly reasonable (and even preferable) for people with >> an understanding of "pointers" from some other language. And for >> those people who don't then one could argue they are a clean slate >> and using the word "pointer" won't hurt. > > No, it is not reasonable. > > You want to insist that `x = 23` in Python code makes x a pointer. But that > Python snippet is analogous to to the following C and Pascal snippets: > > # C > int x = 23; > > [...pascal example snipped...] > > Do you insist that they are pointers to? > > Then everything is a pointer, and the word has no meaning. > > Regardless of which of the three languages we are talking about, the > assignment `x = 23` does not mean "bind some value to x which, when > dereferenced, gives the value 23". > > The value bound to x is 23, not some > indirect pointer to 23. Your problem is that the C snippet is not, as you claim, analogous to the Python snippet
Re: Terminology: "reference" versus "pointer"
Chris Angelico writes: > On Mon, Sep 14, 2015 at 11:22 AM, Akira Li <[email protected]> wrote: >> Steven D'Aprano writes: >> >>> On Mon, 14 Sep 2015 09:17 am, Akira Li wrote: >>> I don't see why the model that can't describe range(1) in Python 3 pretends to be complete. >>> >>> >>> Please explain. >>> >>> range(1) returns a range instance. What is hard about that? >> >> Look at the last example: >> http://thread.gmane.org/gmane.comp.python.general/782626/focus=782704 > > Still not sure what the problem is. As per Python's object model, the > lists contain references to range objects. a contains two references > to the same range object, b contains references to each of two > distinct range objects. What of it? For me, there is no problem. "parcel tags" [1], "box and arrows"[2] are all the same (note: "labelled box"[3] that may contain an object is a different model). The talk about being "complete" is caused by the following quote from Random832 message [4]: If the "parcel tags" model can't show it, then the "parcel tag" model clearly is not a correct and complete depiction of how Python actually works. The purpose of the examples in [5] is to demonstate that neither models are "complete" i.e., there is (obviously) behavior of a Python program that they can't describe. [1] http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#python-has-names [2] http://www.pythontutor.com/visualize.html#code=a0+%3D+a1+%3D+%5B1,+2%5D%0Ab0+%3D+%5B1,+2%5D%0Ab1+%3D+%5B1,+2%5D%0Aa+%3D+%5Ba0,+a1%5D%0Ab+%3D+%5Bb0,+b1%5D%0Adel+a0,+a1,+b0,+b1%0A&mode=display&origin=opt-frontend.js&cumulative=false&heapPrimitives=false&textReferences=false&py=3&rawInputLstJSON=%5B%5D&curInstr=6 [3] http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#other-languages-have-variables [4] http://thread.gmane.org/gmane.comp.python.general/782626/focus=782645 [5] http://thread.gmane.org/gmane.comp.python.general/782626/focus=782704 -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Mon, 14 Sep 2015 11:22 am, Akira Li wrote: > Steven D'Aprano writes: > >> On Mon, 14 Sep 2015 09:17 am, Akira Li wrote: >> >>> I don't see why the model that can't describe range(1) in Python 3 >>> pretends to be complete. >> >> >> Please explain. >> >> range(1) returns a range instance. What is hard about that? > > Look at the last example: > http://thread.gmane.org/gmane.comp.python.general/782626/focus=782704 I'm afraid that page is broken in my browser. Can you not summarise, or link to the specific message? I may be able to use another browser in a day or two, but hopefully the discussion will have moved on by then. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
Steven D'Aprano writes: > On Mon, 14 Sep 2015 11:22 am, Akira Li wrote: >> Look at the last example: >> http://thread.gmane.org/gmane.comp.python.general/782626/focus=782704 > > > I'm afraid that page is broken in my browser. Can you not summarise, or link > to the specific message? I may be able to use another browser in a day or > two, but hopefully the discussion will have moved on by then. https://mail.python.org/pipermail/python-list/2015-September/696631.html -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On 14/09/2015 02:34, rurpy--- via Python-list wrote: Goodbye, *plonk* -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Using enumerate to get line-numbers with itertools grouper?
On Thursday, 3 September 2015 03:49:05 UTC+10, Terry Reedy wrote:
> On 9/2/2015 6:04 AM, Victor Hooi wrote:
> > I'm using grouper() to iterate over a textfile in groups of lines:
> >
> > def grouper(iterable, n, fillvalue=None):
> > "Collect data into fixed-length chunks or blocks"
> > # grouper('ABCDEFG', 3, 'x') --> ABC DEF Gxx
> > args = [iter(iterable)] * n
> > return zip_longest(fillvalue=fillvalue, *args)
> >
> > However, I'd also like to know the line-number that I'm up to, for printing
> > out in informational or error messages.
> >
> > Is there a way to use enumerate with grouper to achieve this?
>
> Without a runnable test example, it is hard to be sure what you want.
> However, I believe replacing 'iter(iterable)' with 'enumerate(iterable,
> 1)', and taking into account that you will get (line_number, line)
> tuples instead of lines, will do what you want.
>
> --
> Terry Jan Reedy
Hi,
Hmm, I've tried that suggestion, but for some reason, it doesn't seem to be
unpacking the values correctly - in this case, line_number and chunk below just
give me two successive items from the iterable:
Below is the complete code I'm running:
#!/usr/bin/env python3
from datetime import datetime
from itertools import zip_longest
def grouper(iterable, n, fillvalue=None):
"Collect data into fixed-length chunks or blocks"
# grouper('ABCDEFG', 3, 'x') --> ABC DEF Gxx
args = [enumerate(iterable, 1)] * n
return zip_longest(fillvalue=fillvalue, *args)
def parse_iostat(lines):
"""Parse lines of iostat information, yielding iostat blocks.
lines should be an iterable yielding separate lines of output
"""
block = None
for line in lines:
line = line.strip()
try:
if ' AM' in line or ' PM' in line: # What happens if their
device names have AM or PM?
tm = datetime.strptime(line, "%m/%d/%Y %I:%M:%S %p")
else:
tm = datetime.strptime(line, "%m/%d/%y %H:%M:%S")
if block: yield block
block = [tm]
except ValueError:
# It's not a new timestamp, so add it to the existing block
# We ignore the iostat startup lines (which deals with random
restarts of iostat), as well as empty lines
if '_x86_64_' not in line:
block.append(line)
if block: yield block
with open('iostat_sample_12hr_time', 'r') as f:
f.__next__() # Skip the "Linux..." line
f.__next__() # Skip the blank line
for line_number, chunk in grouper(parse_iostat(f), 2):
print("Line Number: {}".format(line_number))
print("Chunk: {}".format(chunk))
Here is the input file:
Linux 3.19.0-20-generic (ip-172-31-12-169) 06/25/2015 _x86_64_
(2 CPU)
06/25/2015 07:37:04 AM
avg-cpu: %user %nice %system %iowait %steal %idle
0.020.000.020.000.00 99.95
Device: rrqm/s wrqm/s r/s w/srMB/swMB/s avgrq-sz
avgqu-sz await r_await w_await svctm %util
xvdap10.00 0.040.030.07 0.00 0.0084.96
0.00 30.362.74 42.83 0.53 0.01
xvdb 0.00 0.000.000.00 0.00 0.0011.62
0.000.230.192.13 0.16 0.00
xvdf 0.00 0.000.000.00 0.00 0.0010.29
0.000.410.410.73 0.38 0.00
xvdg 0.00 0.000.000.00 0.00 0.00 9.12
0.000.360.351.20 0.34 0.00
xvdh 0.00 0.000.000.00 0.00 0.0033.35
0.001.390.418.91 0.39 0.00
dm-0 0.00 0.000.000.00 0.00 0.0011.66
0.000.460.460.00 0.37 0.00
06/25/2015 07:37:05 AM
avg-cpu: %user %nice %system %iowait %steal %idle
0.500.000.500.000.00 99.01
Device: rrqm/s wrqm/s r/s w/srMB/swMB/s avgrq-sz
avgqu-sz await r_await w_await svctm %util
xvdap10.00 0.000.000.00 0.00 0.00 0.00
0.000.000.000.00 0.00 0.00
xvdb 0.00 0.000.000.00 0.00 0.00 0.00
0.000.000.000.00 0.00 0.00
xvdf 0.00 0.000.000.00 0.00 0.00 0.00
0.000.000.000.00 0.00 0.00
xvdg 0.00 0.000.000.00 0.00 0.00 0.00
0.000.000.000.00 0.00 0.00
xvdh 0.00 0.000.000.00 0.00 0.00 0.00
0.000.000.000.00 0.00 0.00
dm-0 0.00 0.000.000.00 0.00 0.00 0.00
0.00
