🌐 Mailman 3 December 2014 - Python-list - python.org

TypeError: 'float' object is not iterable
by Ana Dionísio Dec. 16, 2015

Dec. 16, 2015

Hi!! I keep having this error and I don't know why: TypeError: 'float' object is not iterable. I have this piece of code, that imports to python some data from Excel and saves it in a list: " t_amb = [] for i in range(sh2.nrows): t_amb.append(sh2.cell(i,2).value) print t_amb " Here is everything ok. But then, I need to pass the data again to exel, so I wrote this: " a=8 for b in range (len(t_amb)): a=8 for d in t_amb[b]: a=a+1 sheet.write(a,b+1,d) " The error appear in "for d in t_amb[b]:" and I don't understand why. Can you help me?

8 7

Script to extract text from PDF files
by brad Nov. 6, 2015

Nov. 6, 2015

I have a very crude Python script that extracts text from some (and I emphasize some) PDF documents. On many PDF docs, I cannot extract text, but this is because I'm doing something wrong. The PDF spec is large and complex and there are various ways in which to store and encode text. I wanted to post here and ask if anyone is interested in helping make the script better which means it should accurately extract text from most any pdf file... not just some. I know the topic of reading/extracting the text from a PDF document natively in Python comes up every now and then on comp.lang.python... I've posted about it in the past myself. After searching for other solutions, I've resorted to attempting this on my own in my spare time. Using apps external to Python (pdftotext, etc.) is not really an option for me. If someone knows of a free native Python app that does this now, let me know and I'll use that instead! So, if other more experienced programmer are interested in helping make the script better, please let me know. I can host a website and the latest revision and do all of the grunt work. Thanks, Brad

8 10

Determining version of OpenSSL linked against python?
by Adam Mercer Sept. 17, 2015

Sept. 17, 2015

Hi I'm trying to write a script that determines the version of OpenSSL that python is linked against, using python-2.7 this is easy as I can use: import ssl ssl.OPENSSL_VERSION but unfortunately I need to support python-2.6, from an older script I used the following: import _ssl ssl_lib = _ssl.__file__ to get the path to the _ssl.so module and then I parsed the output of ldd (on linux) to get the path to the OpenSSL library and then parsed the version from the filename. In other words it's very messy. I had a little success using this approach but I have recently received a bug report that this doesn't seem to work on Debian Squeeze. When I try to query the __file__ attribute of the _ssl module I get the following error: >>> import _ssl >>> _ssl.__file__ Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'module' object has no attribute '__file__' >>> Can anyone offer any suggestions as to what is going wrong with the above code or offer an alternative way of determining the OpenSSl version using python-2.6? Cheers Adam

3 4

Einstein's Riddle
by Steve Graham Sept. 17, 2015

Sept. 17, 2015

Who would be interested in using his/her brain (and his computer) to solve the following? Steve Graham === Einstein's Riddle Albert Einstein wrote this riddle this century [ed. 20th century]. He said 98% of the world could not solve it. There are 5 houses in 5 different colors. In each house lives a person with a different nationality. The 5 owners drink a certain type of beverage, smoke a certain brand of cigar, and keep a certain pet. No owners have the same pet, smoke the same brand of cigar or drink the same beverage. The question is: "Who owns the fish?" Hints: The Brit lives in the red house. The Sweed keeps dogs as pets. The Dane drinks tea. The green house is on the left of the white house. The green house's owner drinks coffee. The person who smokes Pall Mall rears birds. The owner of the yellow house smokes Dunhill. The man living in the center house drinks milk. The Norwegian lives in the first house. The man who smokes Blends lives next to the one who keeps cats. The man who keeps the horse lives next to the man who smokes Dunhill. The owner who smokes Bluemasters drinks beer. The German smokes Prince. The Norwegian lives next to the blue house. The man who smokes Blends has a neighbor who drinks water.

36 56

Wholesale Sports Shoes Clear Air Force One AAA++quality(www.cnnshoe.com)
by cnnshoe Sept. 12, 2015

Sept. 12, 2015

supply sports shoes. The brand Sports shoes basketball shoes, Boot, walling shoes, Athletic shoes, Jogging shoes, running shoes, leather shoes, football, shoe sports shoe Footwear Sneaker, Shox Max Rift T- shirts, womens t-shirts, Clothing womens clothing, wear hats Caps Jersey jeans Sock Jacks, Watches, wallet, handbags, and Jeans Lady Clothing and so on. Please contact us by email to get more information. please kindly visite our website: http://www.cnnshoe.com msn: cnnshoe2010(a)hotmail.com email: cnnshoe(a)gmail.com

2 1

Python handles globals badly.
by Skybuck Flying Sept. 12, 2015

Sept. 12, 2015

Excuse is: "bad programming style". I don't need snot telling me how to program after 20 years of programming experience. This is so far the only thing pissing me off in python. Now I have to declare "global" in front of these variables every where I want to use em: ShipAbilityDistributeShieldPower ShipAbilityTargetWeaponsSubsystems ShipAbilityTargetEnginesSubsystems ShipAbilityTargetShieldsSubsystems ShipAbilityTargetAuxiliarySubsystems CapTactAbilityAttackPatternAlpha CapTactAbilityFireOnMyMark CapTactAbilityTacticalInitiative CapTactAbilityGoDownFighting CapTactAbilityTacticalFleet CapEngAbilityRotateShieldFrequency CapEngAbilityEPSPowerTransfer CapEngAbilityNadionInversion CapEngAbilityMiracleWorker CapEngAbilityEngineeringFleet CapSciAbilitySensorScan CapSciAbilitySubnucleonicBeam CapSciAbilityScatteringField CapSciAbilityPhotonicFleet CapSciAbilityScienceFleet CapSharedAbilityEvasiveManeuvers CapSharedAbilityBraceForImpact CapSharedAbilityRammingSpeed CapSharedAbilityAbandonShip CapSharedAbilityFleetSupport BoffTactAbilityBeamArrayFireAtWill BoffTactAbilityBeamArrayOverload BoffTactAbilityTacticalTeam BoffTactAbilityTorpedoHighYield BoffTactAbilityTorpedoSpread BoffTactAbilityTargetWeaponsSubsystems BoffTactAbilityTargetEnginesSubsystems BoffTactAbilityTargetShieldsSubsystems BoffTactAbilityTargetAuxiliarySubsystems BoffTactAbilityAttackPatternBeta BoffTactAbilityAttackPatternDelta BoffTactAbilityCannonRapidFire BoffTactAbilityCannonScatterVolley BoffTactAbilityDispersalPatternAlpha BoffTactAbilityDispersalPatternBeta BoffTactAbilityAttackPatternOmega BoffEngAbilityEmergencyPowerToAuxiliary BoffEngAbilityEmergencyPowerToWeapons BoffEngAbilityEmergencyPowerToEngines BoffEngAbilityEmergencyPowerToShields BoffEngAbilityEngineeringTeam BoffEngAbilityAuxiliaryToBattery BoffEngAbilityAuxiliaryToDampeners BoffEngAbilityAuxiliaryToStructural BoffEngAbilityBoardingParty BoffEngAbilityDirectedEnergyModulation BoffEngAbilityExtendShields BoffEngAbilityReverseShieldPolarity BoffEngAbilityAcetonBeam BoffEngAbilityEjectWarpPlasma BoffSciAbilityHazardEmitters BoffSciAbilityJamSensors BoffSciAbilityMaskEnergySignature BoffSciAbilityPolarizeHull BoffSciAbilityScienceTeam BoffSciAbilityTachyonBeam BoffSciAbilityTractorBeam BoffSciAbilityTransferShieldStrength BoffSciAbilityChargedParticleBurst BoffSciAbilityEnergySiphon BoffSciAbilityFeedbackPulse BoffSciAbilityPhotonicOfficer BoffSciAbilityTractorBeamRepulsors BoffSciAbilityScrambleSensors BoffSciAbilityTykensRift BoffSciAbilityGravityWell BoffSciAbilityPhotonicShockwave BoffSciAbilityViralMatrix SpaceSetAbilityAssimilatedBorgTechnologyTractorBeam SpaceSetAbilityRomulanSingularityHarnessPlasmaHyperflux SpaceSetAbilityNukaraStrikeforceTechnologiesUnstableTetryonLattice UniConAbilityPhotonicShockwaveTorpedo UniConAbilityTholianWeb UniConAbilityBattleModule3000BattleMode UniConAbilityBattleModule3000SwarmMissiles UniConAbilitySubspaceRupture UniConAbilityTholianTetryonGrid UniConAbilityIsometricCharge UniConAbilitySpatialChargeLauncher UniConAbilityAcetonAssimilator UniConAbilitySabotageProbeLauncher UniConAbilityRepairPlatform UniConAbilityProjectedSingularity RepNukAbilityTetryonCascade InvAbilitiesNimbusPirateDistressCall CarrierAbilityPetAttackMode PetAbilityLaunchEliteTholianMeshWeavers PetAbilityLaunchAdvancedObeliskSwarmers PetAbilityLaunchEliteScorpionFighters SingCoreAbilityPlasmaShockwave SingCoreAbilityQuantumAbsorption WarpCoreShieldCapacitator KlingonCaptAbilityBattleCloak

21 106

Re: ctypes for AIX
by Anssi Saari July 29, 2015

July 29, 2015

"Waddle, Jim" <jim.waddle(a)boeing.com> writes: > I do not have sufficient knowledge to know how to fix this. I would think that this error somehow is related to compiling on aix. If you have any suggestions on how to correct this problem , I would appreciate it I'd have to guess your main problem is not using gcc to compile. From a quick look, that's what the guys at the pware site did.

2 1

Re: O'Reilly Python Certification
by jaron.breen＠gmail.com July 26, 2015

July 26, 2015

Ethan, Steve, Tim, and others: I'm thinking of taking the program. How long, in hours, does it take to complete all four Python courses? -Jaron Breen On Wednesday, December 15, 2010 12:54:27 PM UTC-5, Ethan Furman wrote: > So I just got an e-mail from O'Reilly and their School of Technology > about a Python Certification course... anybody have any experience with > this? > > It also says Steve Holden is involved -- is this True? (Steve?) > > ~Ethan~ > > PS > > Can you tell I've been programming? ;)

5 4

Re: python 3.4 use python-gcm can't import
by Frank Liou June 3, 2015

June 3, 2015

what? So...My 3.4 can't use this package? now i use http.client reg_ids = [] reg_ids.append(GetCustomerGCMId[0]) API_KEY = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' mydata = {'registration_ids': reg_ids, 'data': data} jqs = json.dumps(mydata) headers = {"Content-type": "application/json", "Authorization": "key="+API_KEY} conn = http.client.HTTPConnection('android.googleapis.com') conn.request('POST', '/gcm/send', jqs, headers) res = conn.getresponse() conn.close() reason = res.reason read = res.read().decode() headers = res.headers result = {'msg': res.status, 'reason': str(res.reason), 'read': str(res.read())} i got status only 200 ok and body is "b'" .....is empty i'm so confused.don't know it work or not

3 2

Re: Language design
by Steven D'Aprano June 2, 2015

June 2, 2015

On Thu, 12 Sep 2013 20:23:21 -0700, Mark Janssen wrote: >>> Really? Are you saying you (and the community at-large) always derive >>> from Object as your base class? >> >> Not directly, that would be silly. > > Silly? "Explicit is better than implicit"... right? If I'm inheriting from str, I inherit from str explicitly: class MyStr(str): ... and then str in turn inherits from object explicitly. I certainly do not inherit from object and then re-implement all the string methods from scratch: class MyStr(object): def __new__(cls, value): ... def upper(self): ... def lower(self): ... # and so on... That would be ridiculous, and goes against the very idea of inheritance. But nor do I feel the need to explicitly list the entire superclass hierarchy: class MyStr(str, object): ... which would be silly. Only somebody who doesn't understand how inheritance works in Python would do that. There's simply no need for it, and in fact it would be actively harmful for larger hierarchies. >>> But wait is it the "base" (at the bottom of the hierarchy) or is it >>> the "parent" at the top? You see, you, like everyone else has been >>> using these terms loosely, confusing yourself. >> >> Depends on whether I'm standing on my head or not. >> >> Or more importantly, it depends on whether I visualise my hierarchy >> going top->down or bottom->up. Both are relevant, and both end up with >> the *exact same hierarchy* with only the direction reversed. > > Ha, "only the direction reversed". That little directionality that > you're passing by so blithely is the difference between whether you're > talking about galaxies or atoms. It makes no difference whether I write: atoms -> stars -> galaxies or galaxies <- stars <- atoms nor does it make any difference if I write the chain starting at the top and pointing down, or at the bottom and pointing up. Your objection implies that writing family trees with the most distant ancestor (the root of the tree) at the top of the page somehow confuses people into thinking that perhaps they are the progenitor of people who lived generations earlier. That's absurd -- people simply are not as stupid as you think. > The simplicity of Python has seduced you into making an "equivocation" > of sorts. It's subtle and no one in the field has noticed it. It crept > in slowly and imperceptively. Ah, and now we come to the heart of the matter -- people have been drawing tree-structures with the root at the top of the page for centuries, and Mark Janssen is the first person to have realised that they've got it all backwards. >>> By inheriting from sets you get a lot of useful functionality for >>> free. That you don't know how you could use that functionality is a >>> failure of your imagination, not of the general idea. >> >> No you don't. You get a bunch of ill-defined methods that don't make >> sense on dicts. > > They are not necessarily ill-defined. Keep in mind Python already chose > (way back in 1.x) to arbitrary overwrite the values in a key collision. > So this problem isn't new. You've simply adapted to this limitation > without knowing what you were missing. No, Python didn't "arbitrarily" choose this behaviour. It is standard, normal behaviour for a key-value mapping, and it is the standard behaviour because it is the only behaviour that makes sense for a general purpose mapping. Python did not invent dicts (although it may have invented the choice of name "dict"). If you think of inheritance in the Liskov Substitution sense, then you might *consider* building dicts on top of sets. But it doesn't really work, because there is no way to sensibly keep set-behaviour for dicts. For example, take intersection of two sets s and t. It is a basic principle of set intersection that s&t == t&s. But now, take two dicts with the same keys but different values, d and e. What values should be used when calculating d&e compared to e&d? Since they are different values, we can either: * prefer the values from the left argument over that from the right; * prefer the values from the right argument over that from the left; * refuse to choose and raise an exception; * consider the intersection empty The first three choices will break the Liskov Substitution Principle, since now dicts *cannot* be substituted for sets. The fourth also breaks Liskov, but for a different reason: # sets (key in s) and (key in t) implies (key in s&t); but # dicts (key in d) and (key in e) *does not* imply (key in d&e) So whatever you do, you are screwed Liskov-wise. You cannot derive dicts from sets and still keep the Liskov Substitution Principle. Of course, LSP is not the only way to design your inheritance hierarchies. An alternative is to design them in terms of delegating implementation to the superclass. As Raymond Hettinger puts it, your classes tells it's parent to do some of the work. But in this case, you're still screwed: you can derive sets from dicts, and in fact the first implementation of sets in Python did exactly that, but you cannot derive dicts from sets. So either way, whether you are an OOP purist who designs your classes with type-theoretic purity and the Liskov Substitution Principle in mind, or a pragmatist who designs your classes with delegation of implementation in mind, you can't sensibly derive dicts from sets. >>>>> 3) It used the set literal for dict, so that there's no obvious way >>>>> to do it. This didn't get changed in Py3k. >>>> >>>> No, it uses the dict literal for dicts. >>> >>> Right. The dict literal should be {:} -- the one obvious way to do >>> it. >> >> I don't agree it is obvious. It is as obvious as (,) being the empty >> tuple or [,] being the empty list. > > You're just being argumentative. If there are sets as built-ins, then > {:} is the obvious dict literal, because {} is the obvious one for set. > You don't need [,] to be the list literal because there is no simpler > list-type. The point is that the obvious way to write an empty collection is using a pair of delimiters, not to shove an arbitrary separator separating nothing at all in there: [] is an empty list, not [,] () is an empty tuple, not (,) {} is an empty (dict|set), not {,} or {:} We can't have {} be both an empty set and an empty dict, so one of the two has to miss out. Neither is more obvious than the other. dicts are more important data structures, and they have historical precedence, so they win. If Python was being re-invented from scratch now, or if sets had been around just as long as dicts, people might have chosen to given sets higher priority than dicts, but frankly I doubt it. It's much more common to want an empty dict than an empty set, at least in my experience. >>>> And the obvious way to form an empty set is by calling set(), the >>>> same as str(), int(), list(), float(), tuple(), dict(), ... >>> >>> Blah, blah. Let me know when you got everyone migrated over to >>> Python.v3. >> >> What does this have to do with Python 3? It works fine in Python 2. > > I mean, you're suggestions are coming from a "believer", not someone > wanting to understand the limitations of python or whether v3 has > succeeded at achieving its potential. "not someone wanting to understand the limitations of python..." -- are you aware that I started this thread? -- Steven

5 6