Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #81824 > unrolled thread

Python handles globals badly.

Back to article view | Back to comp.lang.python

Contents

  Python handles globals badly. "Skybuck Flying" <skybuck2000@hotmail.com> - 2014-12-03 03:27 +0100
    Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2014-12-03 13:35 +1100
    RE: Python handles globals badly. "Clayton Kirkwood" <crk@godblessthe.us> - 2014-12-02 18:53 -0800
    Re: Python handles globals badly. Michael Torrie <torriem@gmail.com> - 2014-12-02 20:13 -0700
      Re: Python handles globals badly. "Skybuck Flying" <skybuck2000@hotmail.com> - 2014-12-03 05:32 +0100
        Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2014-12-03 15:42 +1100
        Re: Python handles globals badly. Dave Angel <davea@davea.name> - 2014-12-03 00:02 -0500
        Re: Python handles globals badly. Michael Torrie <torriem@gmail.com> - 2014-12-02 22:23 -0700
          Re: Python handles globals badly. Marko Rauhamaa <marko@pacujo.net> - 2014-12-03 08:52 +0200
            Re: Python handles globals badly. Joel Goldstick <joel.goldstick@gmail.com> - 2014-12-03 02:17 -0500
        Re: Python handles globals badly. Joshua Landau <joshua@landau.ws> - 2014-12-03 13:07 +0000
        Re: Python handles globals badly. mm0fmf <none@mailinator.com> - 2014-12-03 18:04 +0000
          Re: Python handles globals badly. sohcahtoa82@gmail.com - 2014-12-03 10:16 -0800
            Re: Python handles globals badly. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-12-04 11:57 +1100
              Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2014-12-04 12:10 +1100
              Re: Python handles globals badly. Joel Goldstick <joel.goldstick@gmail.com> - 2014-12-03 20:23 -0500
            Re: Python handles globals badly. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-12-03 22:57 -0500
            Re: Python handles globals badly. Michael Torrie <torriem@gmail.com> - 2014-12-03 21:11 -0700
    Re: Python handles globals badly. Ben Finney <ben+python@benfinney.id.au> - 2014-12-03 14:21 +1100
    Re: Python handles globals badly. "Skybuck Flying" <skybuck2000@hotmail.com> - 2014-12-03 05:17 +0100
      Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2014-12-03 15:36 +1100
      Re: Python handles globals badly. Tony the Tiger <tony@tiger.invalid> - 2014-12-04 20:27 +0000
    Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-12-03 12:35 +0000
      Re: Python handles globals badly. "Skybuck Flying" <skybuck2000@hotmail.com> - 2014-12-04 00:02 +0100
        Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-12-04 01:32 +0000
        Re: Python handles globals badly. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-12-03 23:01 -0500
        Re: Python handles globals badly. jtan <admin@grails.asia> - 2014-12-04 13:03 +0800
          Re: Python handles globals badly. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-12-04 22:35 +1100
            Re: Python handles globals badly. jtan <admin@grails.asia> - 2014-12-04 22:38 +0800
        Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-12-04 10:24 +0000
        Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2014-12-04 21:29 +1100
          Re: Python handles globals badly. Marko Rauhamaa <marko@pacujo.net> - 2014-12-04 14:51 +0200
            Re: Python handles globals badly. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-12-04 20:56 -0500
            Re: Python handles globals badly. William Ray Wing <wrw@mac.com> - 2014-12-04 23:17 -0500
        Re: Python handles globals badly. alister <alister.nospam.ware@ntlworld.com> - 2014-12-04 19:54 +0000
    Re: Python handles globals badly. Peter Pearson <pkpearson@nowhere.invalid> - 2014-12-03 20:31 +0000

Page 1 of 2  [1] 2  Next page →

#81824 — 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 

[toc] | [next] | [standalone]

#81825

On Wed, Dec 3, 2014 at 1:27 PM, Skybuck Flying <skybuck2000@hotmail.com> 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 <insert other language here>, because if it did, what would be
the point of having both?

ChrisA

[toc] | [prev] | [next] | [standalone]

#81826

You're still young, enjoy your youth while you can.

>-----Original Message-----
>From: Python-list [mailto:python-list-
>bounces+crk=godblessthe.us@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

[toc] | [prev] | [next] | [standalone]

#81827

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.

[toc] | [prev] | [next] | [standalone]

#81831

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. 

[toc] | [prev] | [next] | [standalone]

#81833

On Wed, Dec 3, 2014 at 3:32 PM, Skybuck Flying <skybuck2000@hotmail.com> 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

[toc] | [prev] | [next] | [standalone]

#81834

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():
     if    something:
         global.ShipAbilityDistributeShieldPower = 2



-- 
DaveA

[toc] | [prev] | [next] | [standalone]

#81836

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.

[toc] | [prev] | [next] | [standalone]

#81841

> 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

[toc] | [prev] | [next] | [standalone]

#81843

troll

On Wed, Dec 3, 2014 at 1:52 AM, Marko Rauhamaa <marko@pacujo.net> 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

[toc] | [prev] | [next] | [standalone]

#81861

On 3 December 2014 at 04:32, Skybuck Flying <skybuck2000@hotmail.com> wrote:
>
> 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.

If you are being serious, please take into consideration that there is
no way you are going to convince anyone on this list with the way you
are asking. For the most part, people will be convinced when you show
them something that would improve *their* life, not something that
would improve yours. Being an open-source project lead largely by
volunteers, either you convince people on their terms or you go fork
the project.

To do the former, find an example in the standard library or some
popular codebase and show how what you're suggesting could improve the
code. If your example is good, you'll get support for the idea. If the
example is bad, people will point out how better to approach this.

[toc] | [prev] | [next] | [standalone]

#81867

On 03/12/2014 04:32, 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.

Hmm, I smell trolling!

*plonk*

[toc] | [prev] | [next] | [standalone]

#81868

On Wednesday, December 3, 2014 10:05:06 AM UTC-8, mm0fmf wrote:
> On 03/12/2014 04:32, 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.
> 
> Hmm, I smell trolling!
> 
> *plonk*

I'm surprised other people haven't picked up on how obvious of a troll this "Skybuck Flying" guy is.  He claims 20 years programming experience, then uses an absurd amount of globals, many of which are related, without using a data structure of some kind.

> > I am still new at python and definetly don't feel comfortable with the 
object feature,

Someone with 20 years of programming shouldn't have any problems understanding objects in Python.

20 years experience?  Probably more like 20 minutes.

[toc] | [prev] | [next] | [standalone]

#81874

sohcahtoa82@gmail.com wrote:

> On Wednesday, December 3, 2014 10:05:06 AM UTC-8, mm0fmf wrote:
>> On 03/12/2014 04:32, 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.
>> 
>> Hmm, I smell trolling!
>> 
>> *plonk*
> 
> I'm surprised other people haven't picked up on how obvious of a troll
> this "Skybuck Flying" guy is.  He claims 20 years programming experience,
> then uses an absurd amount of globals, many of which are related, without
> using a data structure of some kind.

20 years of maintaining COBOL code first written in 1967 perhaps?

Or more likely, VisualBasic. Skybuck Flying has posted here before:

https://mail.python.org/pipermail/python-list/2013-October/657648.html

Judging from what he considers good style and essential features of a
programming language, I expect that he learned to program in BASIC back in
the days of line numbers and GOTOs, and has barely adapted to a *slightly*
more structured approach in VB.


>> > I am still new at python and definetly don't feel comfortable with the
> object feature,
> 
> Someone with 20 years of programming shouldn't have any problems
> understanding objects in Python.

Oh if that were only the case. It is amazing how long some people can work
in a profession and still avoid learning anything new.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#81875

On Thu, Dec 4, 2014 at 11:57 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
>> Someone with 20 years of programming shouldn't have any problems
>> understanding objects in Python.
>
> Oh if that were only the case. It is amazing how long some people can work
> in a profession and still avoid learning anything new.

I heard that described as "1 year's experience gained 20 times".
Sadly, some people have gained their first year of experience even
more times than that.

ChrisA

[toc] | [prev] | [next] | [standalone]

#81877

On Wed, Dec 3, 2014 at 8:10 PM, Chris Angelico <rosuav@gmail.com> wrote:
> On Thu, Dec 4, 2014 at 11:57 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>>> Someone with 20 years of programming shouldn't have any problems
>>> understanding objects in Python.
>>
>> Oh if that were only the case. It is amazing how long some people can work
>> in a profession and still avoid learning anything new.
>
> I heard that described as "1 year's experience gained 20 times".
> Sadly, some people have gained their first year of experience even
> more times than that.
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list

I especially liked the 'phython' reference in his post from 2013!

-- 
Joel Goldstick
http://joelgoldstick.com

[toc] | [prev] | [next] | [standalone]

#81881

On Wed, 3 Dec 2014 10:16:18 -0800 (PST), sohcahtoa82@gmail.com declaimed
the following:


>
>I'm surprised other people haven't picked up on how obvious of a troll this "Skybuck Flying" guy is.  He claims 20 years programming experience, then uses an absurd amount of globals, many of which are related, without using a data structure of some kind.
>
	My initial impression is of 20 years of Kemeny&Kurtz BASIC... Of the
70s... with everything global.

	 But even I, in high school, would have made most of those "globals" a
set of arrays (especially given the 2-character variable names allowed) and
used documentation (comments) to supply the information on what index value
represented what attribute...

dim sh(20)
rem ship attributes as
rem	(1) distribute shield power
rem	(2) target weapons subsystems

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#81882

On 12/03/2014 08:57 PM, Dennis Lee Bieber wrote:
> On Wed, 3 Dec 2014 10:16:18 -0800 (PST), sohcahtoa82@gmail.com declaimed
> the following:
> 
> 
>>
>> I'm surprised other people haven't picked up on how obvious of a troll this "Skybuck Flying" guy is.  He claims 20 years programming experience, then uses an absurd amount of globals, many of which are related, without using a data structure of some kind.
>>
> 	My initial impression is of 20 years of Kemeny&Kurtz BASIC... Of the
> 70s... with everything global.

BASIC was slow in changing, that's for sure.  I have used BASIC a lot
over the years, and it's been highly structured with modern scoping
rules since about the mid 80s.  Certainly Borland's Turbo BASIC provided
real functions and subroutines, private variables, block structures,
etc.  Sadly BASIC dialects tended to try to maintain backwards
compatibility so even modern dialects like FreeBASIC can be coerced into
executing spaghetti code.  Sad that the OP is stuck in this style of
programming.  Whatever works for him. Maybe instead of Python he should
use FreeBASIC with the -lang qb flag.  Actually, more appropriate might
be PC Basic [1] which is a GW BASIC clone actually written in Python.
Nothing better than executing spaghetti code in an interpreter written
in an interpreted language! Python indeed must be powerful indeed.

[1] http://sourceforge.net/projects/pcbasic

[toc] | [prev] | [next] | [standalone]

#81828

"Skybuck Flying" <skybuck2000@hotmail.com> 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

[toc] | [prev] | [next] | [standalone]

#81830

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. 

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web