Re: Proposed new conditional operator: "or else"
Dennis Lee Bieber wrote: >> foo == 42 or else >> > > Has a PERL stink to it... like: foo == 42 or die I think this statement needs to take ellipsis as well foo == 42 or else ... Sturls -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
troll On Wed, Dec 3, 2014 at 1:52 AM, Marko Rauhamaa wrote: > >> On 12/02/2014 09:32 PM, Skybuck Flying wrote: >>> Some issues I'd like to address to you: >>> >>> 1. Structured programming requires more programming time. >>> 2. Structured programming implies structure which might be less flexible. >>> 3. Python objects require "self" keyword to be used everywhere, and other >>> akwardness wich leads to more typing/programming/writing time. >> >> You forgot to mention that horrible white-space being syntax! Surely >> that is inflexible and awkward! > > Hook... > >>> Lastly I also don't like the module approach in python because the sikuli >>> ide doesn't really support working with multiple files that well. >> >> A poor craftsman blames his tools for his own shortcomings. > > ... line... > >>> Funny thing is these goto statements would be very handy for bot >>> programming, so it's a painfull feature to miss. >> >> Haven't heard that argued in many years. And I don't see how. > > ... and sinker. > > > Marko > -- > https://mail.python.org/mailman/listinfo/python-list -- Joel Goldstick http://joelgoldstick.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Parsing XML Using XPATH for Python
Uzoma Ojemeni writes:
...
One easy option would be to use the "XPath" support in the "lxml"
package -- provided you have not problem with the installation
of external libraries ("libxml2" and "libxslt") and C-extensions ("lxml").
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
> On 12/02/2014 09:32 PM, Skybuck Flying wrote: >> Some issues I'd like to address to you: >> >> 1. Structured programming requires more programming time. >> 2. Structured programming implies structure which might be less flexible. >> 3. Python objects require "self" keyword to be used everywhere, and other >> akwardness wich leads to more typing/programming/writing time. > > You forgot to mention that horrible white-space being syntax! Surely > that is inflexible and awkward! Hook... >> Lastly I also don't like the module approach in python because the sikuli >> ide doesn't really support working with multiple files that well. > > A poor craftsman blames his tools for his own shortcomings. ... line... >> Funny thing is these goto statements would be very handy for bot >> programming, so it's a painfull feature to miss. > > Haven't heard that argued in many years. And I don't see how. ... and sinker. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Cherrypy - prevent browser "prefetch"?
Israel Brewster wrote: Primary because they aren’t forms, they are links. And links are, by definition, GET’s. That said, as I mentioned in earlier replies, if using a form for a simple link is the Right Way to do things like this, then I can change it. I'd look at it another way and say that an action with side effects shouldn't appear as a simple link to the user. Links are for requesting information; buttons are for triggering actions. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Need Help
Greetings, > I'm a beginner of python, I just want your help. We'll gladly do it, however you need to invest some time and write better questions :) See http://www.catb.org/esr/faqs/smart-questions.html > How can I get the Failure values from the Console in to a txt or a csv file? We need more information. What is the test suite you're using? How are you running the tests? Example output ... All the best, -- Miki -- https://mail.python.org/mailman/listinfo/python-list
Re: PyEval_GetLocals and unreferenced variables
Ned Batchelder wrote: I would use thread locals for this: https://docs.python.org/2/library/threading.html#threading.local You could get dynamic scoping that way, but the OP seems to want lexical scoping. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: PyEval_GetLocals and unreferenced variables
Kasper Peeters wrote: I could in principle decide to make these settings a proper Python object, and ask the user to create one and pass it along at every C-function call. I would make the C functions methods of the object holding the settings. Your nested function example would then look something like this: def fun(): cpp = Cpp() cpp.set_some_flag() cpp.cfun(...) def fun2(): cpp2 = Cpp(cpp) cpp2.set_some_other_flag() cpp2.fun(...) Hence my question: how can I ask, purely on the C side, for Python to pull objects into the local frame? You can't. Firstly, it's not possible to add locals to a frame that didn't exist when the bytecode was compiled. The compiler figures out how many locals there are, allocates them in an array, and generates bytecodes that reference them by their array index. I'm not sure how you think you're adding a local from C code. If you're using PyEval_GetLocals(), that only gives you a dict containing a *copy* of the locals; modifying that dict doesn't change the locals in the function's frame. Secondly, the way references to outer scopes is implemented is by effectively passing the referenced variables as implicit parameters. If the bytecode of the nested function doesn't reference a given variable in the outer function, it doesn't get passed in. Again, this is determined when the bytecode is compiled and can't be changed at run time. Final note: I am actually trying to make this look as close as possible to an older custom-built language, which didn't require passing the settings object either, so it's kinda important to make the user feel 'at home'. I doubt it's worth the extreme level of hackery that would be required to make it work, though. I think it would be better to provide a clean, pythonic API that makes the scope of the options explicit, rather than try to mimic another language's dubious implicit scoping features. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On 12/02/2014 09:32 PM, Skybuck Flying wrote: > Some issues I'd like to address to you: > > 1. Structured programming requires more programming time. > 2. Structured programming implies structure which might be less flexible. > 3. Python objects require "self" keyword to be used everywhere, and other > akwardness wich leads to more typing/programming/writing time. You forgot to mention that horrible white-space being syntax! Surely that is inflexible and awkward! > I used to program in Delphi, there I would do everything OO and modular. Python allows you to explicitly use an OO paradigm if you wish, or use a more procedural form, or functional form (to a degree anyway). All the while using and exploiting object-oriented characteristics (modules, attributes, etc) throughout. It's really the best of both worlds. > Lastly I also don't like the module approach in python because the sikuli > ide doesn't really support working with multiple files that well. A poor craftsman blames his tools for his own shortcomings. I suggest you change tools to something a little more flexible (just about anything really) > Even if it did, having all code in one big file is a pretty big adventage. Not really. Keeping things as simple as possible and modular is easier to debug, easier to test, add features to, and easier to understand three months from now. I can tell by your opinions that you've never done any medium to large-scale development before. > So features I miss in python are: "labels" "goto statements" and "repeat > until". Python is newbie friendly (mostly), but it is a far, far more powerful, capable, and expressive language than Delphi ever was. Take a theory of computer languages class some time (create your own language even... Scheme is a good place to start). It might open your eyes a lot. Python is not just a scripting language, it's a powerful application development language that allows me to create code rapidly that actually works. I'm far more productive in Python than in any language I've used to date. > > Funny thing is these goto statements would be very handy for bot > programming, so it's a painfull feature to miss. Haven't heard that argued in many years. And I don't see how. Python has very powerful ways of dispatching execution including dictionaries of functions, callable objects, etc. Sounds like you're programming in a very primitive way, reinventing many structures that Python already has. I know that some low-level C programming does rely on and use goto, but in Python I've never needed it. You're not the first person to not grasp Python fundamentals (such as how variables work with name binding vs the Delphi idea of named boxes that can actually be change; python variables can only be rebound to new objects, unless you call a method on a mutable object), who ends up fighting the language and being really frustrated with it. Sounds like you're trying to code Pascal (or some other language) in Python. This is going to be frustrating. I suggest you learn what it means to code in a "Pythonic" way and you'll find you are really productive and having a lot of fun. -- https://mail.python.org/mailman/listinfo/python-list
Re: html page mail link to webmail program
On 11Nov2014 17:35, Ethan Furman wrote: Okay, the explicit Python question: Clicking on a mail link in a web browser can start an external program. I would like that external program to be a Python script that: opens a new tab in the currently running browser (or a new default browser window), loads up the default web mail client (or one specified if there is no way to know/have a default), navigates to the compose pane (or starts there if possible), enters in the email address from the link that was passed to it, and, if not too much more, move the cursor to the subject field. Surely this can be done in Python. Yes and no. It is dependent on how much control GMail allows you from outside. A quick web search on "open gmail compose using url" led me to this discussion: http://stackoverflow.com/a/8852679 which espouses this URL template: https://mail.google.com/mail/?view=cm&fs=1&to=some...@example.com&su=SUBJECT&body=BODY&bcc=someone.e...@example.com which I have tested, and it works. It does require your browser to be logged into GMail already. Given that, you just need a Python script that can be invoked as a standard browser external mail client accepting the mailto: URL from the browser. Decode the URL into to/subject/etc and then open the right URL using the above template. As an exercise, I wrote a short shell script: https://bitbucket.org/cameron_simpson/css/src/tip/bin-cs/gmail which I would invoke from a shell prompt as: gmail -s "subject line here" j...@blogs.com b...@ben.com ... Adapting it to (a) Python (b) accept a mailto:URL and decoding its fields and (c) opening that URL from inside Python using the "webbrowser" module's: https://docs.python.org/3/library/webbrowser.html#module-webbrowser "open" function I leave as an exercise for the reader. Should take less thatn an hour I'd hope. Cheers, Cameron Simpson Perhaps this morning there were only three Euclidean solids, but god changed its mind retroactively at lunchtime, remaking the whole history of the universe. That's the way it is with omnipotent beings. - mi...@apple.com (Mikel Evins) -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On 12/02/2014 11:32 PM, Skybuck Flying wrote: Some issues I'd like to address to you: 1. Structured programming requires more programming time. 2. Structured programming implies structure which might be less flexible. 3. Python objects require "self" keyword to be used everywhere, and other akwardness wich leads to more typing/programming/writing time. I used the list feature of python to dump these variable in a list so that all variables can be processed by a while loop and so forth. Care to share what you mean by "the list feature"? Perhaps you'd do better with "the dict feature", or "the attribute feature." At first I wanted flexibility and all variables were individually "logic-ed" / "processed" but this became too much code to work with. No meaning without an example. I was also under the impression using many ifs might be faster than lists, but this was bogus information at best. They do entirely different things. Without example code, this statement is also meaningless to me. I wrote a simple short benchmark for if vs list and list performed fast enough for my purposes, it could both handle 500k of items without breaking a sweat, meaning within 1 to 3 seconds or so. I am still new at python and definetly don't feel comfortable with the object feature, though I did use it for these variables which are actually objects. Everything in Python is an object, from ints to functions. That makes lots of things easier and more symmetric. I used to program in Delphi, there I would do everything OO and modular. So why do you no longer want to do that? Lastly I also don't like the module approach in python because the sikuli ide doesn't really support working with multiple files that well. So don't use modules. Nothing about the language forces you to. The main time you might need modules is when you write your second program. Of course, it's nice that somebody else wrote lots of modules for you, the standard library, and PIPI. Python also comes with nice libaries/lists/dictionaries/file io etc.. all easy to use... I haven't tried networking with python yet... that could be funny to try next for my bots :) Anyway this global thing made my doubt if python is a good thing... all in all it wasn't too bad... You still haven't figured out that declaring the occasional global is much less typing than declaring every local. If you're writing code that's mostly using globals, you probably should investigate the tens of thousands of other languages. Though I do hope to see a programming language some day, that is aimed at more mature programmers that know what they are doing. Instead of a language aimed at noobs :) a noob language which forbids certain styles of programming because it would be "bad". That's ridiculous. Python is far from a "noob" language. But when you're a noob, and can still get things accomplished, that's a good thing. Then when you're ready to learn more about the language, asking non-confrontational questions might get you some help. I suggest you learn enough about classes to understand how to make and utilize an object with arbitrary attributes. Even if you did something as crude as: class Dummy(object): pass global = Dummy() global.ShipAbilityDistributeShieldPower = 42 global.ShipAbilityTargetWeaponsSubsystems = 12 ... You can then read and write those values inside functions with no global declarations at all. def myfunc(): ifsomething: global.ShipAbilityDistributeShieldPower = 2 -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On Wed, Dec 3, 2014 at 3:32 PM, Skybuck Flying wrote: > Though I do hope to see a programming language some day, that is aimed at > more mature programmers that know what they are doing. > > Instead of a language aimed at noobs :) a noob language which forbids > certain styles of programming because it would be "bad". If you want assembly language, you know where to find it. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On Wed, Dec 3, 2014 at 3:17 PM, Skybuck Flying wrote: > I hope python one day gets rid of it; > > 1. To stop the confusion. > 2. To stop the doubt. > 3. To stop the wasted lines. > 4. To program with more confidence. > 5. To stop to have to inspect what's going on if one wants to know for sure. > 6. To stop any weird programming mistakes because a global declaration was > not used somewhere in a function, it's probably easier to miss, cause in the > programmers mind he's thinking: "it's global". > > Now it's just some > half-ass-fucked-up-not-really-global-variable-unless-you-specify-it-local-to-be-global-holy-shit-batman-feel-the-brain-pain > ?! > If you want C-like infinitely nested scopes, you basically have to have declared variables, which Python doesn't want. There are other languages which are very Python-like but do have declared variables and infinitely-nested scopes, but I'm not sure I want to deal with this kind of anger on another mailing list, so I won't name one. Once again, though, you need to (a) learn the language before getting irate, and (b) play to its strengths, not its weaknesses. Python's requirement to declare all globals is a major weakness when you have hundreds of globals, so don't do that (or don't complain about how your code looks when you do). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
Some issues I'd like to address to you: 1. Structured programming requires more programming time. 2. Structured programming implies structure which might be less flexible. 3. Python objects require "self" keyword to be used everywhere, and other akwardness wich leads to more typing/programming/writing time. I used the list feature of python to dump these variable in a list so that all variables can be processed by a while loop and so forth. At first I wanted flexibility and all variables were individually "logic-ed" / "processed" but this became too much code to work with. I was also under the impression using many ifs might be faster than lists, but this was bogus information at best. I wrote a simple short benchmark for if vs list and list performed fast enough for my purposes, it could both handle 500k of items without breaking a sweat, meaning within 1 to 3 seconds or so. I am still new at python and definetly don't feel comfortable with the object feature, though I did use it for these variables which are actually objects. I used to program in Delphi, there I would do everything OO and modular. However python feels more like a script language and I am enjoying it quite a lot. I try not to get "entangled" into all kinds of structuring which leads to much time wasted. Though sometimes it can also gain some time. Lastly I also don't like the module approach in python because the sikuli ide doesn't really support working with multiple files that well. Even if it did, having all code in one big file is a pretty big adventage. This allow me to see the code every day I work on it, and think about how to improve the code further, making it faster, more reliable, shorter, and so forth. And it also offers a lot of flexibility and time savings. No need to search in what file, what was located. Python also comes with nice libaries/lists/dictionaries/file io etc.. all easy to use... I haven't tried networking with python yet... that could be funny to try next for my bots :) Anyway this global thing made my doubt if python is a good thing... all in all it wasn't too bad... Though I do hope to see a programming language some day, that is aimed at more mature programmers that know what they are doing. Instead of a language aimed at noobs :) a noob language which forbids certain styles of programming because it would be "bad". There is a word for it in dutch: "beteutelend" I am not sure what the word is in english but it's a bit like "childesh" So features I miss in python are: "labels" "goto statements" and "repeat until". Funny thing is these goto statements would be very handy for bot programming, so it's a painfull feature to miss. Also as already pointed out above structure programming has disadventages as well. I'd like to see other languages which focus at more flexibility instead of structure. Python is already a nice step towards more flexiblity, for example it's auto-type feature is nice, it can detect if a variable is an integer, string or object. Bye, Skybuck. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
Meanwhile... I modified my code, and added these globals in front of it. It didn't take too long to do. But it did add something like 300 "unnecessary" lines of code, which is what kinda annoys me. I'd like to keep my code compact. Anyway I double checked to make sure other routines had global for other variables as well. Perhaps I made some programming mistakes which went unnoticed because of smart code handling optimizations and such. But because the global was omitted perhaps those optimizations never kicked in. I am not completely sure, but so far my bot seems to run real fast. Personally I do not like the way "global" works in python... it sucks quite bad, because it's confusing and inconsistent as hell and it doesn't do anything usefull example: a = 1 def Test() if a == 1: print "hello" return "a" can still be accessed by Test, so this makes it highly confusing ?! Should global be added to a or not ?! This creates doubts among the programmers. Was "a" perhaps maybe initialized or not ? What is it's contents ? The lack of a debugger in Sikuli makes this problem much worse. Only way to know for sure would be to print debug logs of variables which would get a bit excessive to do always, but I guess in case of doubt perhaps it could be done temporarely, however this additional "paranoid" checking does waste some programmer time. Therefore enough reasons for me not to like this... it's weird/akward. I hope python one day gets rid of it; 1. To stop the confusion. 2. To stop the doubt. 3. To stop the wasted lines. 4. To program with more confidence. 5. To stop to have to inspect what's going on if one wants to know for sure. 6. To stop any weird programming mistakes because a global declaration was not used somewhere in a function, it's probably easier to miss, cause in the programmers mind he's thinking: "it's global". Now it's just some half-ass-fucked-up-not-really-global-variable-unless-you-specify-it-local-to-be-global-holy-shit-batman-feel-the-brain-pain ?! Bye, Skybuck. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
"Skybuck Flying" writes: > I don't need snot telling me how to program after 20 years of > programming experience. If you've already determined what advice you do or do not need, then you're welcome to solve your problems by yourself. We'll be here when you decide it's time to humble yourself to the point where you can ask for advice without assuming you already know best. -- \ “But Marge, what if we chose the wrong religion? Each week we | `\ just make God madder and madder.” —Homer, _The Simpsons_ | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On 12/02/2014 07:27 PM, Skybuck Flying wrote: > 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: Only if you want to overwrite them, though. Python has support for any number of programming paradigms. That many global variables is screaming for some kind of organization and Python has good mechanisms for doing this in a much neater way. Might I suggest you use a namespace instead? Put all your "globals" in a module, and refer to them via the module. For example (converting to pep8 which looks better to me): import globals as g def some_func(): g.ship_ability_distribute_shield_power = 5 A whole lot cleaner than trying to use the global keyword everywhere. If you've really been programming for 20 years, surely you're familiar with programming patterns. The fact that you have 6 variables all prefixed with "ShipAbility" should suggest something to you. Like maybe all of these attributes could be encapsulated in one "ship" object. Python is very flexible in how you use objects. You can program in strict java-style if you want, or adopt a more freeform approach: ship = object() ship.ability = object() ship.ability.distribute_shield_power = 5 etc. -- https://mail.python.org/mailman/listinfo/python-list
RE: Python handles globals badly.
You're still young, enjoy your youth while you can. >-Original Message- >From: Python-list [mailto:python-list- >bounces+crk=godblessthe...@python.org] On Behalf Of Skybuck Flying >Sent: Tuesday, December 02, 2014 6:28 PM >To: python-list@python.org >Subject: Python handles globals badly. > >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 > >-- >https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On Wed, Dec 3, 2014 at 1:27 PM, Skybuck Flying wrote: > 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: Well, I'm not snot, and I also have 20+ years' programming experience... and I'm telling you that using that many globals is a poor way to write code. Especially having so many separate, but related, variables. If your two decades' experience were at all like mine, you'll have worked with quite a lot of languages, and you'll know to code to a language's strengths rather than fighting against it. On the other hand, if you've been working with one language for twenty years, then maybe you'd do better to stick to it than to try to learn something new. But either way, don't expect Python to behave like , because if it did, what would be the point of having both? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Python handles globals badly.
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed new conditional operator: "or else"
On 12/02/2014 10:18 AM, Roy Smith wrote: > In the process of refactoring some code, I serendipitously created what I > think is an essential new bit of Python syntax. The “or else” statement. I > ended up with: > > sites_string = args.sites or else self.config['sites'] But isn't that syntactically equivalent of this? sites_string = args.sites or self.config['sites'] Seems to be what you're looking for with "or else" unless I misunderstand what you're proposing. Doing a bit of testing in the interpreter and I find that a combination of Python's truthiness semantics and short-circuit evaluation seems to give a consistent result. Consider: 'a word' or False => 'a word' 'a word' or True => 'a word' False or 'a word' => 'a word' True or 'a word' => True Is this similar to what you'd expect with "or else?" -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed new conditional operator: "or else"
In article , Chris Angelico wrote: > On Wed, Dec 3, 2014 at 4:41 AM, Zachary Ware > wrote: > > On Tue, Dec 2, 2014 at 11:18 AM, Roy Smith wrote: > >> Wouldnât it be neat to write: > >> > >>foo == 42 or else > >> > >> and have that be an synonym for: > >> > >> assert foo == 42 > >> > >> :-) > > > > Never going to happen, but I like it! Perhaps raise IntimidationError > > instead of AssertionError when it fails? > > Definitely. That's what I first thought, when I saw the subject line. > > Additionally, whenever this construct is used, the "yield" statement > (expression, whatever) will be redefined to yield to intimidation and > make the statement true, whatever it takes. In the above example, > "yield" would decide which out of foo and 42 is more amenable to > change, and altering it to be equal to the other. (It may also find > that == is the most amenable, and alter its definition such that foo > and 42 become equal.) > > ChrisA This could be handy in the field of forensic accounting. -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed new conditional operator: "or else"
Zachary Ware wrote: > On Tue, Dec 2, 2014 at 11:18 AM, Roy Smith wrote: >> Wouldn’t it be neat to write: >> >>foo == 42 or else >> >> and have that be an synonym for: >> >> assert foo == 42 >> >> :-) > > Never going to happen, but I like it! Perhaps raise IntimidationError > instead of AssertionError when it fails? I guess the "or else" statement should do this: or else where the statement is executed if the statement evaluates to false. In absence of an explicit threat or else it should raise IntimidationError if evaluates to false false. If evaluates to true it should just return . Sturla -- https://mail.python.org/mailman/listinfo/python-list
Python 2.x vs 3.x survey - new owner?
Last year in late December, I did a brief, 9 question survey of 2.x vs 3.x usage. I like the think the results were interesting, but I don't have the spare cash to do it again this year. I probably shouldn't have done it last year. ^_^ Is anyone interested in taking over the survey? It's on SurveyMonkey. It was mentioned last year, that it might be interesting to see how things change, year to year. It was also reported that some people felt that late December wasn't necessarily the best time of year to do the survey, as a lot of people were on vacation. The Python wiki has last year's results: https://wiki.python.org/moin/2.x-vs-3.x-survey -- https://mail.python.org/mailman/listinfo/python-list
Re: Parsing XML Using XPATH for Python
In Uzoma Ojemeni
writes:
> I am new to Python - a few days old - and I would appreciate some help.
> I want write a python code to parse the below XML as below:-
> ServingCell--NeighbourCell
> L41_NBR3347_1--L41_NBR3347_2
> L41_NBR3347_1--L41_NBR3347_3
> L41_NBR3347_1--L41_NBR3349_1
> L41_NBR3347_1--L41_NBREA2242_1
>
>
>
> 1
>
>
>
> lDot0 lDot0
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
In plain English, it looks like you want to do this:
1. Print a header.
2. For each element:
3. Find the child element.
4. For each child element:
5. Print the "id" attributes of the element and the
element.
Translated to python, that would look something like this:
# import the xml library code
import xml.etree.ElementTree as ET
# load your XML file
tree = ET.parse('cells.xml')
# get the root element
root = tree.getroot()
# print a header
print("ServingCell--NeighbourCell")
# find each child element
for serving_cell in root.findall('LteCell'):
# find the child element
attributes = serving_cell.find('attributes')
# find each child element
for neighbor in attributes.findall('LteNeighboringCellRelation'):
# print the id's of the serving and neighbor cells
print("%s--%s" % (serving_cell.attrib['id'], neighbor.attrib['id']))
--
John Gordon Imagine what it must be like for a real medical doctor to
gor...@panix.comwatch 'House', or a real serial killer to watch 'Dexter'.
--
https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7 and unicode (one more time)
Hi Peter Otten re: There is no assignment soup_atag = whatever but there is one to atag. The whole session should when you omit the offending line > atag = soup_atag.a or insert soup_atag = soup before it. Python 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)] on win 32 Type "help", "copyright", "credits" or "license" for more information. >>> import urllib2 >>> from bs4 import BeautifulSoup >>> html_atag = """Test html a tag example ... http://www.packtpub.com'>Home ... >> soup = BeautifulSoup(html_atag,'lxml') >>> atag = soup.aprint(atag) >>> atag = soup.a >>> print(atag) http://www.packtpub.com'>Home >>> type(atag) >>> tagname = atag.name >>> print tagname a >>> atag.name = 'p' >>> print (soup) Test html a tag example http://www.packtpub.com'>Home >>> atag.name = 'p' >>> print(soup) Test html a tag example http://www.packtpub.com'>Home >>> atag.name = 'a' >>> print(soup) Test html a tag example http://www.packtpub.com'>Home >>> soup_atag = soup >>> atag = soup_atag.a >>> print (atag['href']) http://www.packtpub.com'>Home >> Thank you. Yours Simon. -- https://mail.python.org/mailman/listinfo/python-list
UK Python Training Day
Are you interested in Python training for yourself or others? Can you get to London on 9 December, 2014? If so I would very much like to meet you, and have reserved a venue in Westminster with refreshments and lunch. Starting in 2015 I plan to do more training in Europe (initially in the UK) and so would like to discuss the kind of Python training that will be most effective in those markets. The event starts at 10:00 am and runs until 4:40 pm. If you would like to attend for lunch then reservations are required, and are otherwise helpful. Please sign up at https://www.eventbrite.com/e/uk-python-training-day-tickets-14720737121 regards Steve -- Steve Holden st...@holdenweb.com +1 571 484 6266 @holdenweb -- https://mail.python.org/mailman/listinfo/python-list
Re: Cherrypy - prevent browser "prefetch"?
On Tue, Dec 2, 2014, at 10:59, Israel Brewster wrote: > Primary because they aren’t forms, they are links. And links are, by > definition, GET’s. That said, as I mentioned in earlier replies, if using > a form for a simple link is the Right Way to do things like this, then I > can change it. As I understand it, the usual way to do this these days is to have a link which, A) when navigated to, provides a simple standalone form confirming the action with a button and B) when clicked on with a browser with javascript enabled, automatically submits a hidden form, or an AJAX/JSON request or something, to accomplish the same task skipping the standalone page entirely. This will also have the effect of keeping these entries out of your browser history. Any action which has harmful or annoying side effects should definitely not be a GET. -- https://mail.python.org/mailman/listinfo/python-list
Parsing XML Using XPATH for Python
I am new to Python - a few days old - and I would appreciate some help. I want write a python code to parse the below XML as below:- ServingCell--NeighbourCell L41_NBR3347_1--L41_NBR3347_2 L41_NBR3347_1--L41_NBR3347_3 L41_NBR3347_1--L41_NBR3349_1 L41_NBR3347_1--L41_NBREA2242_1 1 lDot0lDot0 -- https://mail.python.org/mailman/listinfo/python-list
Re: Cherrypy - prevent browser "prefetch"?
In Nobody writes: > On Mon, 01 Dec 2014 11:28:42 -0900, Israel Brewster wrote: > > I'm running to a problem, specifically from > > Safari on the Mac, where I start to type a URL, and Safari auto-fills the > > rest of a random URL matching what I started to type, and simultaneously > > sends a request for that URL to my server, occasionally causing unwanted > > effects. > A GET request should not cause *any* effects. That's what PUT/POST are > for. > GET is for retrieval, not modification. GET shouldn't cause any business data modifications, but I thought it was allowed for things like logging out of your session. -- John Gordon Imagine what it must be like for a real medical doctor to gor...@panix.comwatch 'House', or a real serial killer to watch 'Dexter'. -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed new conditional operator: "or else"
On 2014-12-02 17:41:06 +, Zachary Ware said: foo == 42 or else Never going to happen, but I like it! Perhaps raise IntimidationError instead of AssertionError when it fails? That should probably be a DONTPANICError in large, friendly terminal font letters. -- Andrea -- https://mail.python.org/mailman/listinfo/python-list
Re: How about some syntactic sugar for " __name__ == '__main__' "?
On 02Dec2014 02:17, Ethan Furman wrote: On 12/01/2014 05:15 PM, Chris Angelico wrote: On Tue, Dec 2, 2014 at 11:45 AM, Ethan Furman wrote: Put the above somewhere in your path (e.g. /usr/local/bin), make it executable, and then instead of shebanging your scripts with `/usr/local/bin/python` you can use `/usr/local/bin/py_main`, which will load and execute the script, calling script.main as its last act. Be aware that this trick (shebanging to a script rather than a binary) isn't specified by the POSIX standard. It works on Linux, but I don't know about other systems. Ah, thanks for that! I'm pretty sure I've used systems where you could not shebang to a script. Solaris IIRC. Several years ago, might not be an issue on modern releases. Cheers, Cameron Simpson For reading rec.moto, I use one of those carbon-fiber Logitech mice w/a little 'No Fear' sticker on it. - Mike Hardcore DoD#5010 Apologies to Primus -- https://mail.python.org/mailman/listinfo/python-list
Re: Cherrypy - prevent browser "prefetch"?
On Mon, 01 Dec 2014 11:28:42 -0900, Israel Brewster wrote: > I'm running to a problem, specifically from > Safari on the Mac, where I start to type a URL, and Safari auto-fills the > rest of a random URL matching what I started to type, and simultaneously > sends a request for that URL to my server, occasionally causing unwanted > effects. A GET request should not cause *any* effects. That's what PUT/POST are for. GET is for retrieval, not modification. -- https://mail.python.org/mailman/listinfo/python-list
Re: i have to create this patch in python but wasnt having any luck i was wondering if anyone had a solution?
On Mon, Dec 1, 2014 at 2:28 PM, python help required
<19aada...@gmail.com> wrote:
> def penultimatePatch():
>
> win = GraphWin("Patch1",(100), 100)
> amountOfCircles = 5
>
> #Filled Red Circles
> fillCircle = Circle(Point(20,20)+100/amountOfCircles)
> fillCircle.draw(win)
> fillCircle.setFill("red")
>
> #Verticle white rectangles
> rectangleVerticle1 = Rectangle(Point(0,0), Point(10,100))
> rectangleVerticle1.setFill("white")
> rectangleVerticle1.setOutline("white")
> rectangleVerticle1.draw(win)
The above, and all below should be put in a function like so:
def rectangle_function(rectangle_name, Point(0,0), Point(10,100)):
#Verticle white rectangles
rectangle_name = Rectangle(Point(0,0), Point(10,100))
rectangle_name.setFill("white")
rectangle_name.setOutline("white")
rectangle_name.draw(win)
>
> rectangleVerticle2 = Rectangle(Point(41,0), Point(51,100))
> rectangleVerticle2.setFill("white")
> rectangleVerticle2.setOutline("white")
> rectangleVerticle2.draw(win)
>
> rectangleVerticle3 = Rectangle(Point(81,0), Point(91,100))
> rectangleVerticle3.setFill("white")
> rectangleVerticle3.setOutline("white")
> rectangleVerticle3.draw(win)
>
> #Horizontal white rectangles
> rectangleHorizontal = Rectangle(Point(21,11), Point(41,21))
> rectangleHorizontal.setFill("white")
> rectangleHorizontal.setOutline("white")
> rectangleHorizontal.draw(win)
>
> rectangleHorizontal = Rectangle(Point(61,11), Point(81,21))
> rectangleHorizontal.setFill("white")
> rectangleHorizontal.setOutline("white")
> rectangleHorizontal.draw(win)
>
> rectangleHorizontal = Rectangle(Point(21,31), Point(51,41))
> rectangleHorizontal.setFill("white")
> rectangleHorizontal.setOutline("white")
> rectangleHorizontal.draw(win)
>
> rectangleHorizontal = Rectangle(Point(81,31), Point(61,41))
> rectangleHorizontal.setFill("white")
> rectangleHorizontal.setOutline("white")
> rectangleHorizontal.draw(win)
>
> rectangleHorizontal = Rectangle(Point(21,51), Point(51,61))
> rectangleHorizontal.setFill("white")
> rectangleHorizontal.setOutline("white")
> rectangleHorizontal.draw(win)
>
> rectangleHorizontal = Rectangle(Point(61,51), Point(91,61))
> rectangleHorizontal.setFill("white")
> rectangleHorizontal.setOutline("white")
> rectangleHorizontal.draw(win)
>
> rectangleHorizontal = Rectangle(Point(21,71), Point(51,81))
> rectangleHorizontal.setFill("white")
> rectangleHorizontal.setOutline("white")
> rectangleHorizontal.draw(win)
>
> rectangleHorizontal = Rectangle(Point(61,71), Point(81,81))
> rectangleHorizontal.setFill("white")
> rectangleHorizontal.setOutline("white")
> rectangleHorizontal.draw(win)
>
> rectangleHorizontal = Rectangle(Point(21,91), Point(51,100))
> rectangleHorizontal.setFill("white")
> rectangleHorizontal.setOutline("white")
> rectangleHorizontal.draw(win)
>
> rectangleHorizontal = Rectangle(Point(61,91), Point(91,100))
> rectangleHorizontal.setFill("white")
> rectangleHorizontal.setOutline("white")
> rectangleHorizontal.draw(win)
>
> #Outlined Red circles
> fillCircle = Circle(Point(20,20)+100/amountOfCircles)
> fillCircle.draw(win)
> fillCircle.setOutline("red")
>
> it is supposed to create this design>>> http://i.stack.imgur.com/2dfGi.jpg
> --
> https://mail.python.org/mailman/listinfo/python-list
What results did you get? If you get a traceback, copy it completely
and paste it in your response.
--
Joel Goldstick
http://joelgoldstick.com
--
https://mail.python.org/mailman/listinfo/python-list
Re: Proposed new conditional operator: "or else"
Tim Chase : >> >foo == 42 or else > > In light of the parallel thread discussing the "assert" statement and > the perils of trusting it to be present even though it can be > optimized away, this "or else" could be (in the altered words of Don > Corleone), "I'm gonna make an assertion he can't refuse." I would consider vain threats an antipattern. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed new conditional operator: "or else"
On 2014-12-02 11:41, Zachary Ware wrote: > On Tue, Dec 2, 2014 at 11:18 AM, Roy Smith wrote: > > Wouldn’t it be neat to write: > > > >foo == 42 or else > > > > and have that be an synonym for: > > > > assert foo == 42 > > > > :-) > > Never going to happen, but I like it! Perhaps raise > IntimidationError instead of AssertionError when it fails? In light of the parallel thread discussing the "assert" statement and the perils of trusting it to be present even though it can be optimized away, this "or else" could be (in the altered words of Don Corleone), "I'm gonna make an assertion he can't refuse." (not that I particularly want/expect this in the language definition, but it's fun to entertain the idea) -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed new conditional operator: "or else"
On Wed, Dec 3, 2014 at 4:41 AM, Zachary Ware wrote: > On Tue, Dec 2, 2014 at 11:18 AM, Roy Smith wrote: >> Wouldn’t it be neat to write: >> >>foo == 42 or else >> >> and have that be an synonym for: >> >> assert foo == 42 >> >> :-) > > Never going to happen, but I like it! Perhaps raise IntimidationError > instead of AssertionError when it fails? Definitely. That's what I first thought, when I saw the subject line. Additionally, whenever this construct is used, the "yield" statement (expression, whatever) will be redefined to yield to intimidation and make the statement true, whatever it takes. In the above example, "yield" would decide which out of foo and 42 is more amenable to change, and altering it to be equal to the other. (It may also find that == is the most amenable, and alter its definition such that foo and 42 become equal.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed new conditional operator: "or else"
On 12/02/2014 09:41 AM, Zachary Ware wrote: > On Tue, Dec 2, 2014 at 11:18 AM, Roy Smith wrote: >> >> Wouldn’t it be neat to write: >> >>foo == 42 or else >> >> and have that be an synonym for: >> >> assert foo == 42 > > Never going to happen, but I like it! Perhaps raise IntimidationError > instead of AssertionError when it fails? As long as when raising Intimidation, it also roughs up a couple surrounding lines as a warning to the rest of the code... -- ~Ethan~ signature.asc Description: OpenPGP digital signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed new conditional operator: "or else"
On Tue, Dec 2, 2014 at 11:18 AM, Roy Smith wrote: > Wouldn’t it be neat to write: > >foo == 42 or else > > and have that be an synonym for: > > assert foo == 42 > > :-) Never going to happen, but I like it! Perhaps raise IntimidationError instead of AssertionError when it fails? -- Zach -- https://mail.python.org/mailman/listinfo/python-list
Proposed new conditional operator: "or else"
In the process of refactoring some code, I serendipitously created what I think is an essential new bit of Python syntax. The “or else” statement. I ended up with: sites_string = args.sites or else self.config['sites'] which, of course, is a syntax error today, but it got me thinking what we could do with an “or else” construct. Perhaps an alternative to assertions? Wouldn’t it be neat to write: foo == 42 or else and have that be an synonym for: assert foo == 42 :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Cherrypy - prevent browser "prefetch"?
> On Dec 2, 2014, at 4:33 AM, random...@fastmail.us wrote: > > On Mon, Dec 1, 2014, at 15:28, Israel Brewster wrote: >> For example, I have a URL on my Cherrypy app that updates some local >> caches. It is accessed at http:///admin/updatecaches So if I >> start typing http:///a, for example, safari may auto-fill the >> "dmin/updatecaches", and trigger a cache refresh on the server - even >> though I was just trying to get to the main admin page at /admin. Or, it >> might auto-fill "uth/logout" instead (http:///auth/logout), and >> log me out of my session. While the former may be acceptable (after all, >> a cache update, even if not strictly needed, is at least non-harmfull), >> the latter could cause serious issues with usability. So how can cherrypy >> tell the difference between the "prefetch" and an actual request, and not >> respond to the prefetch? > > Why is your logout form - or, your update caches form, etc - a GET > instead of a POST? Primary because they aren’t forms, they are links. And links are, by definition, GET’s. That said, as I mentioned in earlier replies, if using a form for a simple link is the Right Way to do things like this, then I can change it. Thanks! — Israel Brewster > The key problem is that a GET request is assumed by > browser designers to not have any harmful side effects. > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Cherrypy - prevent browser "prefetch"?
On Mon, Dec 1, 2014, at 15:28, Israel Brewster wrote: > For example, I have a URL on my Cherrypy app that updates some local > caches. It is accessed at http:///admin/updatecaches So if I > start typing http:///a, for example, safari may auto-fill the > "dmin/updatecaches", and trigger a cache refresh on the server - even > though I was just trying to get to the main admin page at /admin. Or, it > might auto-fill "uth/logout" instead (http:///auth/logout), and > log me out of my session. While the former may be acceptable (after all, > a cache update, even if not strictly needed, is at least non-harmfull), > the latter could cause serious issues with usability. So how can cherrypy > tell the difference between the "prefetch" and an actual request, and not > respond to the prefetch? Why is your logout form - or, your update caches form, etc - a GET instead of a POST? The key problem is that a GET request is assumed by browser designers to not have any harmful side effects. -- https://mail.python.org/mailman/listinfo/python-list
Re: PyEval_GetLocals and unreferenced variables
On 12/2/14 4:35 AM, Kasper Peeters wrote: def fun(): cfun_that_creates_q_in_local_scope() def fun2(): cfun_that_wants_to_see_if_q_is_available() So the Python side actually doesn't see 'q' directly at all. I think you will need to elaborate. Ok, here goes (and thanks for listening). The behaviour of the C side is determined by certain settings/preferences. I want these settings to respect the Python scope. I could in principle decide to make these settings a proper Python object, and ask the user to create one and pass it along at every C-function call. Something like def fun(): settings = Cpp_Options() settings.set_some_flag() cfun(settings, ...) def fun2(): settings = Cpp_Options(settings) settings.set_some_other_flag() cfun(settings, ...) Then Python would automatically take care of the scope of 'settings'. However, this is difficult for the user to keep track of. So my idea was to allow for def fun(): set_some_flag() cfun(...) def fun2(): set_some_other_flag() cfun(...) I let the C side create a Cpp_Options object on the locals stack behind the scenes, and the 'cfun()' function takes it from there directly, without requiring the user to pass it. Much easier for the user. This works, but the problem is that the C side does not see the settings that were created in fun() when it gets called from fun2(). In fun2(), the locals do not contain objects constructed earlier in fun(), unless the Python side explicitly refers to them. So adding a line settings.do_something() inside fun2() would work and forces Python to pull the settings object created in fun() into scope, but that sort of defeats the purpose. I would use thread locals for this: https://docs.python.org/2/library/threading.html#threading.local They act like global variables, in that they are available implicitly without being passed around, but like locals in that two separate threads will have different values. -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
2nd call for notes about Eric IDE
In view of next edition of the Eric IDE Technical Report (forecast: 3rd quarter '15) and notably with reference to the innovative Eric ver. no. 6, we'll welcome your testimony of experiences and use of specific Eric IDE's features; such as: – Special features of your choice, as: SQL Browser, Qt Forms Designer, Debug Remote Configurable, Eric APIs, PEP 8 Compliance Syntax and Tabnanny Checks, … – Any other feature of your choice you deem as not adequately documented by the “Eric Tech. Reports” as currently available at URL: http://eric-ide.python-projects.org/eric-documentation.html Please send notes to: Studio-PM hotmail com. Thanks. See you. - P.M. -- https://mail.python.org/mailman/listinfo/python-list
Re: How about some syntactic sugar for " __name__ == '__main__' "?
On 12/01/2014 05:15 PM, Chris Angelico wrote: > On Tue, Dec 2, 2014 at 11:45 AM, Ethan Furman wrote: >> >> Put the above somewhere in your path (e.g. /usr/local/bin), make it >> executable, and then instead of shebanging your >> scripts with `/usr/local/bin/python` you can use `/usr/local/bin/py_main`, >> which will load and execute the script, >> calling script.main as its last act. > > Be aware that this trick (shebanging to a script rather than a binary) > isn't specified by the POSIX standard. It works on Linux, but I don't > know about other systems. Ah, thanks for that! -- ~Ethan~ signature.asc Description: OpenPGP digital signature -- https://mail.python.org/mailman/listinfo/python-list
ANN: eGenix mxODBC Connect 2.1.2 - Python Database Interface
ANNOUNCING eGenix.com mxODBC Connect Python Database Interface Version 2.1.2 mxODBC Connect is our commercially supported client-server product for connecting Python applications to relational databases in a truly platform independent way. This announcement is also available on our web-site for online reading: http://www.egenix.com/company/news/eGenix-mxODBC-Connect-2.1.2-GA.html INTRODUCTION The mxODBC Connect Database Interface for Python allows users to easily connect Python applications to all major databases on the market today in a highly portable, convenient and secure way. Python Database Connectivity the Easy Way - Unlike our mxODBC Python extension, mxODBC Connect is designed as client-server application, so you no longer need to find production quality ODBC drivers for all the platforms you target with your Python application. Instead you use an easy to install royalty-free Python client library which connects directly to the mxODBC Connect database server over the network. This makes mxODBC Connect a great basis for writing cross-platform multi-tier database applications and utilities in Python, especially if you run applications that need to communicate with databases such as MS SQL Server and MS Access, Oracle Database, IBM DB2 and Informix, Sybase ASE and Sybase Anywhere, MySQL, PostgreSQL, SAP MaxDB and many more, that run on Windows or Linux machines. Ideal for Database Driven Client Applications - By removing the need to install and configure ODBC drivers on the client side and dealing with complicated network setups for each set of drivers, mxODBC Connect greatly simplifies deployment of database driven client applications, while at the same time making the network communication between client and database server more efficient and more secure. For more information, please have a look at the mxODBC Connect product page, in particular, the full list of available features. For more information, please see the product page: http://www.egenix.com/products/python/mxODBCConnect/ NEWS mxODBC Connect 2.1.2 is a patch level release of our successful mxODBC Connect product. In the last patch level release 2.1.1, we had put a lot of emphasis on enhancing the TLS/SSL setup of the mxODBC Connect product: https://cms.egenix.com/company/news/eGenix-mxODBC-Connect-2.1.1-GA.html In this release, we are fixing a pip installation problem, that occurred with the mxODBC Connect Client on a few platforms, as well as a some other minor issues we found: Security Enhancements - * OpenSSL cipher string list updated to explicitly disallow use of low security or export ciphers. mxODBC Connect Enhancements --- * Fixed a problem that could cause the mxODBC Connect Client to not install correctly with pip. * Successfully tested against Python 2.7.9, which will come with a new ssl module. * Fixed the package version number to show the correct release version. * Fixed OpenSSL warnings in the Unix installer and scripts. For the full set of changes, including those of the 2.1 series of mxODBC Connect, please check the mxODBC Connect change log: http://www.egenix.com/products/python/mxODBCConnect/changelog.html UPGRADING You are encouraged to upgrade to this latest mxODBC Connect release. When upgrading, please always upgrade both the server and the client installations to the same version - even for patch level releases. We will give out 20% discount coupons for upgrade purchases going from mxODBC Connect Server 1.x to 2.1 and 50% coupons for upgrades from mxODBC 2.x to 2.1. Please contact the eGenix.com Sales Team (sa...@egenix.com) with your existing license serials for details. Users of our stand-alone mxODBC product will have to purchase new licenses from our online shop in order to use mxODBC Connect. You can request free 30-day evaluation licenses by visiting our web-site or writing to sa...@egenix.com, stating your name (or the name of the company) and the number of eval licenses that you need. http://www.egenix.com/products/python/mxODBCConnect/#Evaluation DOWNLOADS The download archives as well as instructions for installation and configuration of the product can be found on the product page: http://www.egenix.com/products/python/mxODBCConnect/ If you want to try the package, jump straight to the download instructions: https://cms.egenix.com/products/python
Re: PyEval_GetLocals and unreferenced variables
> > def fun(): > >cfun_that_creates_q_in_local_scope() > >def fun2(): > >cfun_that_wants_to_see_if_q_is_available() > > > > So the Python side actually doesn't see 'q' directly at all. > > I think you will need to elaborate. Ok, here goes (and thanks for listening). The behaviour of the C side is determined by certain settings/preferences. I want these settings to respect the Python scope. I could in principle decide to make these settings a proper Python object, and ask the user to create one and pass it along at every C-function call. Something like def fun(): settings = Cpp_Options() settings.set_some_flag() cfun(settings, ...) def fun2(): settings = Cpp_Options(settings) settings.set_some_other_flag() cfun(settings, ...) Then Python would automatically take care of the scope of 'settings'. However, this is difficult for the user to keep track of. So my idea was to allow for def fun(): set_some_flag() cfun(...) def fun2(): set_some_other_flag() cfun(...) I let the C side create a Cpp_Options object on the locals stack behind the scenes, and the 'cfun()' function takes it from there directly, without requiring the user to pass it. Much easier for the user. This works, but the problem is that the C side does not see the settings that were created in fun() when it gets called from fun2(). In fun2(), the locals do not contain objects constructed earlier in fun(), unless the Python side explicitly refers to them. So adding a line settings.do_something() inside fun2() would work and forces Python to pull the settings object created in fun() into scope, but that sort of defeats the purpose. Hence my question: how can I ask, purely on the C side, for Python to pull objects into the local frame? Final note: I am actually trying to make this look as close as possible to an older custom-built language, which didn't require passing the settings object either, so it's kinda important to make the user feel 'at home'. Hope this makes it more clear, thanks for your patience. Cheers, Kasper -- https://mail.python.org/mailman/listinfo/python-list
