Re: for convenience
Yes, Chris, you can do all kinds of useful things in Python and I can not make much of a case for requiring a pre-processor. The main reason would be to make code that interprets faster or produces a smaller file of Python commands. All I was saying was that there might be a scenario where a textual replacement method could happen the way Paul sort of guessed. I note that some Python files can be partially processed once into bytecode and then run many times. That may be a level where a preprocessor phase might customize it better so what runs is already half-configured. And as noted, anyone porting code from another language where the code is already segmented with #IFDEF statements and other such fairly primitive methods might have to work harder to move that too into their Python program. I vaguely recall having to write such a preprocessor once upon a time as an exercise for a programming class and it definitely would have been much easier to do in Python. -Original Message- From: Chris Angelico To: python-list@python.org Sent: Thu, Mar 24, 2022 7:57 pm Subject: Re: for convenience On Fri, 25 Mar 2022 at 10:44, Avi Gross wrote: > But would it be helpful? Maybe. I am thinking back to decades ago when I > did C and C++ programming and how we used it. It was way more that just: > > #DEFINE TIMEZONE 5 > > The above use is sort of to create a constant. What we often used was ways > to customize the code so different code would be compiled say when testing > or to work one way on machine A with operating system A' versus machines > B and C, perhaps with different needs and abilities. Sometimes all kinds > of features only made it into one version of the other. The compiler saw > different code each time. Yes, I'm aware of how it was used... but to what extent is that actually necessary in Python? When do you ever need something that you can't do with simple conditional function definition or something of the sort? Textual manipulation lets you create all manner of nightmares. A lot of them are acceptable evils because of the benefits gained, but you'd be hard-pressed to pitch those same benefits to Python programmers, where most of the differences are already handled by (eg) the functions in the os module. > I have also written many things that effectively are read by an early stage > and selected regions are parsed and replaced with code in another language > so that by the time a compiler or interpreter sees it, ... > > So sure, you could write code that reads fileA.py and outputs fileB.py and > only > run fileB through the interpreter. Yes, instead of making versions which have > all > kinds of text written in various languages, you could just have the python > code > read in various files at run time or other techniques. And that's what I meant by having your own preprocessor. I've done various DSLs that way, having something that effectively compiles to Python code. (I've also used Python to write preprocessors for things in other languages, since Python is excellent at text manipulation and even has things like JavaScript lexers available on PyPI.) But the best of these are NOT things that the C preprocessor would be capable of. They can have arbitrarily complex levels of syntactic comprehension, making them far safer to work with. ChrisA -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: for convenience
Chris: > To a very large degree, the rules are and must be the same regardless > of the library/module. I may not have been clear. I am aware of all kinds of mini-languages such as various forms of regular expressions where some string contains a fairly complex program using existing symbols like [~* and so on with no real relationship to the language being employed. You can often write code using an identical regular expression and use it with functions in Python, Perl, R, C++ and lots of other languages. Similarly, the printf() family has a guiding string that uses symbols like % and : and others as a sort of mini language that is often independent of the language it is being used in. Yes, some languages contain functions that only support a subset of functionality or a superset. For example, some allow you to specify an argument that you want Perl-style matching enhancements. So, no, I do not think what I was talking about is necessarily completely the same as what the main language uses. And another example is how you can sometimes change the underlying language at run time by all kinds of techniques such as replacing built-in functions, and in languages like R, creating all kinds of new functionality as in the pipes I mentioned including brand new top-level operators or back in Python, tricks like making a new class inherit from a standard class that then over-rides and augments or even plays games with multiple inheritance. I will agree that fundamentally the overall infrastructure seems the same. But in my view, some changes step out of the original language. As I have also mentioned, there are ways to get a program to perform calculations in a shared way with two or more languages with data moving back and forth as needed. Definitely that example, which I sometimes use in my programming, literally jumps out of the initial language. -Original Message- From: Chris Angelico To: python-list@python.org Sent: Thu, Mar 24, 2022 1:37 pm Subject: Re: for convenience On Fri, 25 Mar 2022 at 04:15, Avi Gross via Python-list wrote: > Python made lots of choices early on and then tried to graft on ever more > features, sometimes well and sometimes not optimally. The same is true > for so many other languages. A carefully designed new language built now > might analyze and make changes. This is technically true, but it's important to keep in mind that it's very difficult to understand the reasons behind all the choices in a language, so if you were to craft your own language now, you would run the risk of throwing away *good* decisions too. > I would even argue that a new language might deliberately include a > pre-processor that works more like Paul first assumed, perhaps as > something that could be turned on and off so it only operated on designated > sections or only when some command-line switch asked for it. Some might > use that, especially if migrating code from a language that had used similar > constructs. But preprocessors work best in compiled code where it is > reasonable > to make multiple passes across a changing text but not so much in an > interpreted environment that tries to read and parse things once or in small > defined chunks dynamically evaluated. No, I would say that a preprocessor of that sort isn't necessary to a Python-like language. If you really want one, it's honestly not that hard to do; remember, "preprocessor" means that it processes the source code before the main language sees it, so you can do that even with Python as it currently is. But I suggest that a naive preprocessor like C's wouldn't be of much benefit. Much more interesting is the possibility of designing a language with a proper grammar, which you then compile to Python code and execute. (Part of the reason that a naive preprocessor wouldn't work well is that it would play very badly with dynamic lookups. Good luck making those work with a source-code transformation.) > But Languages, human as well as computer, can differ widely and yet seem > natural enough to most humans who grew up with them. One of my first human > languages is not big on "gender" and many sentences are exactly the same no > matter if it was being done by a male or female or anything else. So when I > later > learned German with tons of grammar that included three genders, that was > annoying. > Later I learned English and it seemed more civilized to me but in some ways > not. > Is there really a right way to say put verbs first versus last or place > adjectives > before versus after what they modify? Well every darn language I learn has > differences in these ways including exceptions and special cases galore. And > even the choice of genders for words like "ship" or "road" vary widely across > languages. You either memorize or give up, or mor
Re: for convenience
On Fri, 25 Mar 2022 at 10:44, Avi Gross wrote: > But would it be helpful? Maybe. I am thinking back to decades ago when I > did C and C++ programming and how we used it. It was way more that just: > > #DEFINE TIMEZONE 5 > > The above use is sort of to create a constant. What we often used was ways > to customize the code so different code would be compiled say when testing > or to work one way on machine A with operating system A' versus machines > B and C, perhaps with different needs and abilities. Sometimes all kinds > of features only made it into one version of the other. The compiler saw > different code each time. Yes, I'm aware of how it was used... but to what extent is that actually necessary in Python? When do you ever need something that you can't do with simple conditional function definition or something of the sort? Textual manipulation lets you create all manner of nightmares. A lot of them are acceptable evils because of the benefits gained, but you'd be hard-pressed to pitch those same benefits to Python programmers, where most of the differences are already handled by (eg) the functions in the os module. > I have also written many things that effectively are read by an early stage > and selected regions are parsed and replaced with code in another language > so that by the time a compiler or interpreter sees it, ... > > So sure, you could write code that reads fileA.py and outputs fileB.py and > only > run fileB through the interpreter. Yes, instead of making versions which have > all > kinds of text written in various languages, you could just have the python > code > read in various files at run time or other techniques. And that's what I meant by having your own preprocessor. I've done various DSLs that way, having something that effectively compiles to Python code. (I've also used Python to write preprocessors for things in other languages, since Python is excellent at text manipulation and even has things like JavaScript lexers available on PyPI.) But the best of these are NOT things that the C preprocessor would be capable of. They can have arbitrarily complex levels of syntactic comprehension, making them far safer to work with. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: for convenience
Chris: > No, I would say that a preprocessor of that sort isn't necessary to a > Python-like language. If you really want one, it's honestly not that > hard to do; remember, "preprocessor" means that it processes the > source code before the main language sees it, so you can do that even > with Python as it currently is. > But I suggest that a naive preprocessor like C's wouldn't be of much > benefit. Much more interesting is the possibility of designing a > language with a proper grammar, which you then compile to Python code > and execute. > (Part of the reason that a naive preprocessor wouldn't work well is > that it would play very badly with dynamic lookups. Good luck making > those work with a source-code transformation.) Again, Chris, I tend to agree and my point was not that Python needs some preprocessor stage but that if it did, then it might make transformations more on a textual level like Paul initially expected. But would it be helpful? Maybe. I am thinking back to decades ago when I did C and C++ programming and how we used it. It was way more that just: #DEFINE TIMEZONE 5 The above use is sort of to create a constant. What we often used was ways to customize the code so different code would be compiled say when testing or to work one way on machine A with operating system A' versus machines B and C, perhaps with different needs and abilities. Sometimes all kinds of features only made it into one version of the other. The compiler saw different code each time. I have also written many things that effectively are read by an early stage and selected regions are parsed and replaced with code in another language so that by the time a compiler or interpreter sees it, ... So sure, you could write code that reads fileA.py and outputs fileB.py and only run fileB through the interpreter. Yes, instead of making versions which have all kinds of text written in various languages, you could just have the python code read in various files at run time or other techniques. -Original Message- From: Chris Angelico To: python-list@python.org Sent: Thu, Mar 24, 2022 1:37 pm Subject: Re: for convenience On Fri, 25 Mar 2022 at 04:15, Avi Gross via Python-list wrote: > Python made lots of choices early on and then tried to graft on ever more > features, sometimes well and sometimes not optimally. The same is true > for so many other languages. A carefully designed new language built now > might analyze and make changes. This is technically true, but it's important to keep in mind that it's very difficult to understand the reasons behind all the choices in a language, so if you were to craft your own language now, you would run the risk of throwing away *good* decisions too. > I would even argue that a new language might deliberately include a > pre-processor that works more like Paul first assumed, perhaps as > something that could be turned on and off so it only operated on designated > sections or only when some command-line switch asked for it. Some might > use that, especially if migrating code from a language that had used similar > constructs. But preprocessors work best in compiled code where it is > reasonable > to make multiple passes across a changing text but not so much in an > interpreted environment that tries to read and parse things once or in small > defined chunks dynamically evaluated. No, I would say that a preprocessor of that sort isn't necessary to a Python-like language. If you really want one, it's honestly not that hard to do; remember, "preprocessor" means that it processes the source code before the main language sees it, so you can do that even with Python as it currently is. But I suggest that a naive preprocessor like C's wouldn't be of much benefit. Much more interesting is the possibility of designing a language with a proper grammar, which you then compile to Python code and execute. (Part of the reason that a naive preprocessor wouldn't work well is that it would play very badly with dynamic lookups. Good luck making those work with a source-code transformation.) > But Languages, human as well as computer, can differ widely and yet seem > natural enough to most humans who grew up with them. One of my first human > languages is not big on "gender" and many sentences are exactly the same no > matter if it was being done by a male or female or anything else. So when I > later > learned German with tons of grammar that included three genders, that was > annoying. > Later I learned English and it seemed more civilized to me but in some ways > not. > Is there really a right way to say put verbs first versus last or place > adjectives > before versus after what they modify? Well every darn language I learn has > differences in these way
Re: for convenience
On Fri, 25 Mar 2022 at 06:05, Grant Edwards wrote: > > On 2022-03-24, Chris Angelico wrote: > > > No, I would say that a preprocessor of that sort isn't necessary to a > > Python-like language. If you really want one, it's honestly not that > > hard to do; remember, "preprocessor" means that it processes the > > source code before the main language sees it, so you can do that even > > with Python as it currently is. > > And they're best used to make it look like you're actually programming > in a different language. You can make your C program look like BASIC, > or your Python program look like Pascal! > > The best part is that nobody else will be able to figure out WTH is > going on, even if they are fluent in _both_ of the languages! > > Amaze your friends! > > Turn complete strangers into enemies! > Yes! This is, in a sense, the counterpart to polyglot code, where the same script can be run with any of several interpreters. Both are extremely effective at turning people's brains to mush. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: for convenience
On 2022-03-24, Chris Angelico wrote: > No, I would say that a preprocessor of that sort isn't necessary to a > Python-like language. If you really want one, it's honestly not that > hard to do; remember, "preprocessor" means that it processes the > source code before the main language sees it, so you can do that even > with Python as it currently is. And they're best used to make it look like you're actually programming in a different language. You can make your C program look like BASIC, or your Python program look like Pascal! The best part is that nobody else will be able to figure out WTH is going on, even if they are fluent in _both_ of the languages! Amaze your friends! Turn complete strangers into enemies! -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: for convenience
On Fri, 25 Mar 2022 at 04:15, Avi Gross via Python-list wrote: > Python made lots of choices early on and then tried to graft on ever more > features, sometimes well and sometimes not optimally. The same is true > for so many other languages. A carefully designed new language built now > might analyze and make changes. This is technically true, but it's important to keep in mind that it's very difficult to understand the reasons behind all the choices in a language, so if you were to craft your own language now, you would run the risk of throwing away *good* decisions too. > I would even argue that a new language might deliberately include a > pre-processor that works more like Paul first assumed, perhaps as > something that could be turned on and off so it only operated on designated > sections or only when some command-line switch asked for it. Some might > use that, especially if migrating code from a language that had used similar > constructs. But preprocessors work best in compiled code where it is > reasonable > to make multiple passes across a changing text but not so much in an > interpreted environment that tries to read and parse things once or in small > defined chunks dynamically evaluated. No, I would say that a preprocessor of that sort isn't necessary to a Python-like language. If you really want one, it's honestly not that hard to do; remember, "preprocessor" means that it processes the source code before the main language sees it, so you can do that even with Python as it currently is. But I suggest that a naive preprocessor like C's wouldn't be of much benefit. Much more interesting is the possibility of designing a language with a proper grammar, which you then compile to Python code and execute. (Part of the reason that a naive preprocessor wouldn't work well is that it would play very badly with dynamic lookups. Good luck making those work with a source-code transformation.) > But Languages, human as well as computer, can differ widely and yet seem > natural enough to most humans who grew up with them. One of my first human > languages is not big on "gender" and many sentences are exactly the same no > matter if it was being done by a male or female or anything else. So when I > later > learned German with tons of grammar that included three genders, that was > annoying. > Later I learned English and it seemed more civilized to me but in some ways > not. > Is there really a right way to say put verbs first versus last or place > adjectives > before versus after what they modify? Well every darn language I learn has > differences in these ways including exceptions and special cases galore. And > even the choice of genders for words like "ship" or "road" vary widely across > languages. You either memorize or give up, or more likely, make lots of small > mistakes that mark you as a non-native speaker. Yes, and despite what some people try to claim, they're not just all the same thing with different symbols :) Languages ARE different, different in real ways that make them good at different things. > Languages like Python are actually a bit more of a challenge. Like many modern > languages that have been overhauled to support multiple programming > methods/styles > (like object-oriented and functional programming) and that have been extended > with > endless add-ons with names like modules and packages, it seems anything you > learn > may turn out to be "wrong" in the sense that others write code completely > differently > than you first expected. You may learn base Python and think you use lists > for all > kinds of things and maybe even lists of lists to emulate matrices, for > example. > > Then one day someone shows you a program done almost completely using modules > like numpy and pandas and scipy and so on with bits and pieces of what looks > like > python to glue it together. Some add-ons define entirely new mini-languages > whose > rules only make sense within narrow areas and do not generalize. To a very large degree, the rules are and must be the same regardless of the library/module. > It is very common > to have half a dozen ways to do anything, like formatting stuff to print even > within the > base language. That's because formatting things into strings is such an incredibly broad subject that it's best handled in multiple ways :) You could equally say that there are half a dozen ways to do arithmetic, which there are (or even more, in fact). > This reminds me too much of a recent debate here on whether the word "ELSE" > means one > thing versus another in a new context and I think we had to agree to > disagree. Clearly > some of us are primed to see it one way and some the other and neither of > them is right > but also there is NOW a right way to view the construct within Python because > it is what it > is so get over it! I think "if/else" and "try/else" are close enough that nobody should have any concerns about it, and that "for/else" is
Re: for convenience
using modules
like numpy and pandas and scipy and so on with bits and pieces of what looks
like
python to glue it together. Some add-ons define entirely new mini-languages
whose
rules only make sense within narrow areas and do not generalize. It is very
common
to have half a dozen ways to do anything, like formatting stuff to print even
within the
base language.
So for many/most people, intuition from other experiences may not be the best
guide.
Lots of reading helps, and especially books that spell out some hidden
assumptions
such as books written say for C programmers wanting to learn Python which may
also
tell you what stuff from C is not carried over, or what work-around is used
instead, and
even try to instill a concept of what is deemed Pythonic thinking.
I have interacted offline with Paul (and others here) a bit. Paul is quite
intelligent but
also in a somewhat new arena and is learning. Often the best way to learn is by
asking questions and applying the answers. I have had people who assumed a
language
passed values to functions by reference and others by value, and yet others who
wondered
if there was a way to specify which in a given circumstance. Others assumed it
would get
evaluated before the function is called and yet others that it would only get
evaluated later.
There are so many such "choices" in how a language might work and I have seen
all the
above and more across languages, but generally within a language, you need to
ask
what it DOES and then accept that and work with it.
This reminds me too much of a recent debate here on whether the word "ELSE"
means one
thing versus another in a new context and I think we had to agree to disagree.
Clearly
some of us are primed to see it one way and some the other and neither of them
is right
but also there is NOW a right way to view the construct within Python because
it is what it
is so get over it!
-Original Message-
From: Paul St George
To: python-list@python.org
Sent: Thu, Mar 24, 2022 6:31 am
Subject: Re: for convenience
On 22/03/2022 18.04, dn wrote:
> and thank you - it is refreshing, if not enervating, to receive feedback
> on efforts-expended!
>
> You will also notice, that now you understand the id() stuff, the
> tag-team effect between @Chris and I (which we have often played, albeit
> not by-design), now makes sense as an whole (if you didn't quite follow,
> earlier).
>
>
> My research-topic is Cognitive Psychology (how we learn - albeit not
> usually in Python). I found this conversation useful, and may well apply
> it as an example (with your permission, and suitably anonymised) - one
> doesn't need to be a 'computer person' to follow the logic and thus
> realise the dissonance!
>
> While learning (this part of) Python and adding to 'previous
> experience', you formed a "mental-model" of how things work (just as we
> all do). However, when it came time to implement this knowledge:
>
> - you created a 'situation'
> - (all) things didn't 'work' (which also required realisation)
> - you analysed and rationalised (but noted inconsistency)
> - you asked a question (which many of us quickly understood)
> - you've learned/corrected
>
>
> The 'issue' is *not* a fault on your part, nor (necessarily) a lack of
> learning or a lack of effort. So, no criticism from me!
>
> The (under-lying) lesson, is that we (as trainers, but with application
> to all helpers, pair-programmers, mentors, documentation-writers, et al
> - working with less-experienced colleagues) shouldn't spout a whole load
> of 'facts', 'rules', and formulae/s - which we expect to be committed to
> memory. We need to help form a 'correct' mental-model ("correct" being
> defined by the Python interpreter and 'the Python gods' who build it -
> big "thank you" to them!).
>
> Accordingly, my criticism of tests/exams which require recitation of
> facts ("parroting"), compared with "mastery" (can you actually DO what
> is being asked). More importantly, and finally getting to the point:
> 'tests' should be defined to reveal these (personal) 'quirks' of
> learning/understanding, which led to a 'faulty' mental-model!
>
> Your rationale made sense, was logical and understandable. How are you
> to know that Python deems it 'wrong'? (until a 'test' shows you!)
>
> The 'interest' should not be on the people who, and all the 'answers'
> which, were 'correct'. What is more informative, is why someone (aside
> from guessing, ie intelligent, reasonable, after learning the material,
> exert
Re: for convenience
On 22/03/2022 18.04, dn wrote:
> and thank you - it is refreshing, if not enervating, to receive feedback
> on efforts-expended!
>
> You will also notice, that now you understand the id() stuff, the
> tag-team effect between @Chris and I (which we have often played, albeit
> not by-design), now makes sense as an whole (if you didn't quite follow,
> earlier).
>
>
> My research-topic is Cognitive Psychology (how we learn - albeit not
> usually in Python). I found this conversation useful, and may well apply
> it as an example (with your permission, and suitably anonymised) - one
> doesn't need to be a 'computer person' to follow the logic and thus
> realise the dissonance!
>
> While learning (this part of) Python and adding to 'previous
> experience', you formed a "mental-model" of how things work (just as we
> all do). However, when it came time to implement this knowledge:
>
> - you created a 'situation'
> - (all) things didn't 'work' (which also required realisation)
> - you analysed and rationalised (but noted inconsistency)
> - you asked a question (which many of us quickly understood)
> - you've learned/corrected
>
>
> The 'issue' is *not* a fault on your part, nor (necessarily) a lack of
> learning or a lack of effort. So, no criticism from me!
>
> The (under-lying) lesson, is that we (as trainers, but with application
> to all helpers, pair-programmers, mentors, documentation-writers, et al
> - working with less-experienced colleagues) shouldn't spout a whole load
> of 'facts', 'rules', and formulae/s - which we expect to be committed to
> memory. We need to help form a 'correct' mental-model ("correct" being
> defined by the Python interpreter and 'the Python gods' who build it -
> big "thank you" to them!).
>
> Accordingly, my criticism of tests/exams which require recitation of
> facts ("parroting"), compared with "mastery" (can you actually DO what
> is being asked). More importantly, and finally getting to the point:
> 'tests' should be defined to reveal these (personal) 'quirks' of
> learning/understanding, which led to a 'faulty' mental-model!
>
> Your rationale made sense, was logical and understandable. How are you
> to know that Python deems it 'wrong'? (until a 'test' shows you!)
>
> The 'interest' should not be on the people who, and all the 'answers'
> which, were 'correct'. What is more informative, is why someone (aside
> from guessing, ie intelligent, reasonable, after learning the material,
> exerting effort...) got it 'wrong' - but thought his/her path was true!
> --
> Regards,
> =dn
Wow, this is super interesting. You have my permission, and please feel free to
contact me offline if you want to ask anything.
Yes, I had noticed the tandem with @Chris. I think I needed both! I already
have a folder on my Mac called ‘Cameron’. Perhaps I now need an additional
folder. Then I can ask my question about whether Python grows to be more like
its programmers, or do programmers learn to think Pythonically?
—
Paul St George
--
https://mail.python.org/mailman/listinfo/python-list
Re: convenience
> On 22 Mar 2022, at 18:00, Avi Gross via Python-list > wrote: > > An earlier post talked about a method they used for "convenience" in a way > they apparently did not understand and many of us educated them, hopefully. > > That made me wonder of teh impact on our code when we use various forms > of convenience. Is it convenient for us as programmers, other potential > readers, > or a compiler or interpreter? Using aliases can impose a cost for maintenance. It adds a burden on the reader to figure what an alias really refers to. I encountered this: from time import time as now. The use of now() was just confusing to maintainers. I avoid the convenience path as it often makes maintenance harder. > > The example used was something like: > > varname = objectname.varname > > The above clearly requires an existing object. But there is no reason it > has to be the same name. Consider the somewhat related idea used > almost always in code: > > import numpy as np > > Both cases make a sort of pointer variable and are a tad shorter to write. > > But what impact does it have on interpreters and compilers? On the positive side aliases are very useful to improve the speed of hot-path code. read = this.that.the_other.read while condition: buf = read() ... As with all optimisations only do this if you can justify it with benchmark results. Barry -- https://mail.python.org/mailman/listinfo/python-list
Re: convenience
Greg, Yes, what I describe may not be common and some code goes to serious lengths precisely to make direct connections to internals on an object hard to access. But Python indeed allows and perhaps encourages you to use what you consider side effects but perhaps more. There are many dunder methods that allow all sorts of side effects or direct effects. You can set it up so an access of a variable increments a counter but perhaps it can set it up so three tries at guessing a password disables it or refuses to accept a number out of your bounds. Or it may be that some accesses to say write a value might also update several other values. For example, if you store a distance and also a time, any change of either one resets the value of a stored item holding a velocity. Perhaps adding additional values (or removing any) results in an immediate recalculation of the mean or standard deviation or whatever. If you allow direct access then you can make changes that get around that and I see no reason to assume programs do not use such ideas. Perhaps worse is that items may be dynamic. If an object representing me and my library card checks out a book, a new object may be created that holds the book. If you copy a pointer to the reference to the book in the library card object and later the book is returned and a new book checked out, then your reference is now pointing to the old book. If your goal is to get to the CURRENT book, you failed! So I stand by my suggestion that unless you know the code well and can be sure you won't corrupt things, this kind of convenient access has possible dangers. -Original Message- From: Greg Ewing To: python-list@python.org Sent: Tue, Mar 22, 2022 7:12 pm Subject: Re: convenience On 23/03/22 7:00 am, Avi Gross wrote: > But are there costs or even errors > if you approach an inner part of an object directly? Can there be dunder > methods not > invoked that would be from the standard approach? What kind of inadvertent > errors can creep in? The attribute could be a property that returns different objects at different times depending on some condition. In that case you will need to think about whether you want the current value of the attribute, or the value it had when you looked it up before. Concerning dunder methods, there are a bunch of them involved in looking up an attribute of an object. Theoretically it's possible for these to have side effects and for bad things to happen if you skip them. But that would be very unusual and surprising, and we generally assume such things don't happen. -- Greg -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: convenience
On 23/03/22 7:00 am, Avi Gross wrote: But are there costs or even errors if you approach an inner part of an object directly? Can there be dunder methods not invoked that would be from the standard approach? What kind of inadvertent errors can creep in? The attribute could be a property that returns different objects at different times depending on some condition. In that case you will need to think about whether you want the current value of the attribute, or the value it had when you looked it up before. Concerning dunder methods, there are a bunch of them involved in looking up an attribute of an object. Theoretically it's possible for these to have side effects and for bad things to happen if you skip them. But that would be very unusual and surprising, and we generally assume such things don't happen. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: for convenience
I sent George a private reply as discussing other languages gets rapidly off-topic. I want to add a small addendum here about the technique he used and a Dave Neal and others are trying, a way to imagine things that is more compatible with how a language like Python works so it meets expectation. Your example was name= obj.name and you saw it as a convenience. But consider some form of linked list, perhaps a multidimensional one like a tree or generalized graph. If you are traversing the list there is a concept of following a sort of pointer to the "next" and once there following that to the "next" and so on, till you find what you want or reach a leaf node and back up and so on. So your routine may have multiple lines that look like: here = here.next As you traverse, "here" keeps moving and a sublist or subtree or whatever lies below you. It is not a convenience but a portable way to keep track of your current location. It keeps changing. And, in some cases, you retreat back and follow a nextleft or nextright pointer of sorts. In examples like that, the construct is not for convenience but simply because it makes no sense to approach an arbitrary data structure and have to say first.next.next.next.next ... Also noted is your use of a direct pointer had positive and also negative ramifications to consider. It is not a synonym just for convenience. -Original Message- From: Paul St George To: python-list@python.org Sent: Tue, Mar 22, 2022 4:52 pm Subject: Re: for convenience On 21/03/2022 17.47, Avi Gross wrote: > So, I ask Paul what other language than python he has used before, just out > of curiosity. The other language I have used (and often) is Processing. Before that, and a long time ago, Lingo. — Paul -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: for convenience
On 23/03/2022 09.23, Paul St George wrote:
> On 21/03/2022 18.04, dn wrote:
>
>> On 22/03/2022 10.17, Chris Angelico wrote:
>>> On Tue, 22 Mar 2022 at 08:13, Paul St George >> <https://mail.python.org/mailman/listinfo/python-list>> wrote:
>>>>
>>>>
>>>> When I am writing code, I often do things like this:
>>>>
>>>> context = bpy.context # convenience
>>>>
>>>> then whenever I need bpy.context, I only need to write context
>>>>
>>>>
>>>> Here’s my question:
>>>>
>>>> When I forget to use the convenient shorter form
>>>>
>>>> why is bpy.context not interpreted as bpy.bpy.context?
>>>>
>>>
>>> I don't understand the question. When you do that "for convenience"
>>> assignment, what you're doing is creating a local variable named
>>> "context" which refers to the same thing that bpy.context does (or did
>>> at the time of the assignment, but presumably you only do this when
>>> bpy.context won't get reassigned). It has no effect on any other name.
>>> There's no magic happening here - it's just assignment to the name
>>> context, like anything else.
>>>
>>> What are you expecting to happen here?
>>
>>
>> It's the way Python works.
>>
>> try:
>>
>> context = bpy.context # convenience
>> print( id(context), id(bpy.context) )
>>
>> Remember that the 'relationship' between the two is established at
>> run-time and at the data/address 'level' - and not at compile-time. Thus
>> "context" points to a memory location, and does not 'stand for'
>> "bpy.context" anywhere other than in your mind.
>>
>> (which is why we often need to use a copy() when we want 'separate data'
>> - see also the 'counters' Python uses to manage "garbage collection")
>>
>> --
>> Regards,
>> =dn
>
>
> Thanks dn,
> I did exactly as you suggested.
>
> import bpy
>
> context = bpy.context # convenience variable
> print( id(context), id(bpy.context) )
>
> 4932508928 4932508928
>
> The two are the same, and that makes it crystal clear. And, as a bonus you
> have explained a use of copy().
>
> —
> Thanks,
> Paul
and thank you - it is refreshing, if not enervating, to receive feedback
on efforts-expended!
You will also notice, that now you understand the id() stuff, the
tag-team effect between @Chris and I (which we have often played, albeit
not by-design), now makes sense as an whole (if you didn't quite follow,
earlier).
My research-topic is Cognitive Psychology (how we learn - albeit not
usually in Python). I found this conversation useful, and may well apply
it as an example (with your permission, and suitably anonymised) - one
doesn't need to be a 'computer person' to follow the logic and thus
realise the dissonance!
While learning (this part of) Python and adding to 'previous
experience', you formed a "mental-model" of how things work (just as we
all do). However, when it came time to implement this knowledge:
- you created a 'situation'
- (all) things didn't 'work' (which also required realisation)
- you analysed and rationalised (but noted inconsistency)
- you asked a question (which many of us quickly understood)
- you've learned/corrected
The 'issue' is *not* a fault on your part, nor (necessarily) a lack of
learning or a lack of effort. So, no criticism from me!
The (under-lying) lesson, is that we (as trainers, but with application
to all helpers, pair-programmers, mentors, documentation-writers, et al
- working with less-experienced colleagues) shouldn't spout a whole load
of 'facts', 'rules', and formulae/s - which we expect to be committed to
memory. We need to help form a 'correct' mental-model ("correct" being
defined by the Python interpreter and 'the Python gods' who build it -
big "thank you" to them!).
Accordingly, my criticism of tests/exams which require recitation of
facts ("parroting"), compared with "mastery" (can you actually DO what
is being asked). More importantly, and finally getting to the point:
'tests' should be defined to reveal these (personal) 'quirks' of
learning/understanding, which led to a 'faulty' mental-model!
Your rationale made sense, was logical and understandable. How are you
to know that Python deems it 'wrong'? (until a 'test' shows you!)
The 'interest' should not be on the people who, and all the 'answers'
which, were 'correct'. What is more informative, is why someone (aside
from guessing, ie intelligent, reasonable, after learning the material,
exerting effort...) got it 'wrong' - but thought his/her path was true!
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list
Re: for convenience
On 21/03/2022 17.47, Avi Gross wrote: > So, I ask Paul what other language than python he has used before, just out > of curiosity. The other language I have used (and often) is Processing. Before that, and a long time ago, Lingo. — Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: for convenience
On 21/03/2022 18.02, Cameron Simpson wrote: > On 21Mar2022 22:12, Paul St George wrote: > >When I am writing code, I often do things like this: > > > >context = bpy.context # convenience > > > >then whenever I need bpy.context, I only need to write context > > > > > >Here’s my question: > > > >When I forget to use the convenient shorter form > > > >why is bpy.context not interpreted as bpy.bpy.context? > > Because it still has its original meaning. You haven't changed the > meaning of the word "context" in any position, you have simply made a > module level name "context" referring to the same object to which > "bpy.context" refers. > > So your module global namespace contains, initially, "bpy". Then you > assign: > > context = bpy.context > > and now your module global namespace contains "bpy" and "context". But > "bpy.context" is still what it was, because "bpy" is an object and you > have done nothing to its ".context" attribute. > > Consider this code: > > class O: > pass > > o = O() > o.x = 3 > > x = o.x > > print(x) > print(o.x) > > I expect to see "3" twice. What do you expect? > > "bpy" is no different to "o" - it's just a name. Thanks Cameron, What did I expect? Well, I expected to see "3” twice, but I did not understand why. Now I do! — Thanks, Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: for convenience
On 21/03/2022 18.04, dn wrote: > On 22/03/2022 10.17, Chris Angelico wrote: > > On Tue, 22 Mar 2022 at 08:13, Paul St George > <https://mail.python.org/mailman/listinfo/python-list>> wrote: > >> > >> > >> When I am writing code, I often do things like this: > >> > >> context = bpy.context # convenience > >> > >> then whenever I need bpy.context, I only need to write context > >> > >> > >> Here’s my question: > >> > >> When I forget to use the convenient shorter form > >> > >> why is bpy.context not interpreted as bpy.bpy.context? > >> > > > > I don't understand the question. When you do that "for convenience" > > assignment, what you're doing is creating a local variable named > > "context" which refers to the same thing that bpy.context does (or did > > at the time of the assignment, but presumably you only do this when > > bpy.context won't get reassigned). It has no effect on any other name. > > There's no magic happening here - it's just assignment to the name > > context, like anything else. > > > > What are you expecting to happen here? > > > It's the way Python works. > > try: > > context = bpy.context # convenience > print( id(context), id(bpy.context) ) > > Remember that the 'relationship' between the two is established at > run-time and at the data/address 'level' - and not at compile-time. Thus > "context" points to a memory location, and does not 'stand for' > "bpy.context" anywhere other than in your mind. > > (which is why we often need to use a copy() when we want 'separate data' > - see also the 'counters' Python uses to manage "garbage collection") > > -- > Regards, > =dn Thanks dn, I did exactly as you suggested. import bpy context = bpy.context # convenience variable print( id(context), id(bpy.context) ) 4932508928 4932508928 The two are the same, and that makes it crystal clear. And, as a bonus you have explained a use of copy(). — Thanks, Paul -- https://mail.python.org/mailman/listinfo/python-list
convenience
An earlier post talked about a method they used for "convenience" in a way
they apparently did not understand and many of us educated them, hopefully.
That made me wonder of teh impact on our code when we use various forms
of convenience. Is it convenient for us as programmers, other potential readers,
or a compiler or interpreter?
The example used was something like:
varname = objectname.varname
The above clearly requires an existing object. But there is no reason it
has to be the same name. Consider the somewhat related idea used
almost always in code:
import numpy as np
Both cases make a sort of pointer variable and are a tad shorter to write.
But what impact does it have on interpreters and compilers?
I assume objectname.varname makes the interpreter look up "objectname" in
some stack of namespaces and find it. Then it looks within the namespace
inside the object and finds varname. Finally, it does whatever you asked for
such
as getting or setting a value or something more complex.
So what happens if you simply call "varname" after the above line of code has
set it to be a partial synonym for the longer name? Clearly it no longer does
any
work on evaluating "objectname" and that may be a significant saving as the
name may be deep in the stack of namespaces. But are there costs or even errors
if you approach an inner part of an object directly? Can there be dunder
methods not
invoked that would be from the standard approach? What kind of inadvertent
errors can creep in?
I have seen lots of errors in many languages and functions designed to make
some things superficially easier. Sometimes it involves adding a namespace
to the stack of namespaces that contains the names of all column names
of a DataFrame, for example to avoid extra typing, and this can make fairly
complex and long pieces of code way shorter. But this can also make other
existing names go deeper into the stack and temporarily shadowed or if
a similar technique is used a bit later in the code while this is in effect, can
shadow it as in opening another object of the same kind.
Sometimes there is a price for convenience. And even if you are fully
aware of the pitfalls, and expect to gain from the convenience to you
or even the interpreter, your work may be copied or expanded on by
others who do not take care. In the example above in a language like R,
you can add the namespace to the environment and use it in read-only mode
but writing to a resulting variable like "col1" makes a new local variable and
does
not make any change to the underlying filed in a data.frame.
I mean (again this is not Python code) that:
mydata$result <- mydata$col1 + mydata$col2
will create or update a column called "result" within the data.frame called
mydata,
BUT
with(mydata, result <- col1 + col2)
That does not work well and leaves "result" alone or non-existent. Instead, a
local variable
called result is created and then rapidly abandoned as shown by code that
displays it:
with(mydata, {result <- col1 + col2; print(result)})
The above returns 3 when the columns in mydata are 1 and 2.
Just FYI, there are other packages that handle such short names properly and
well, but they
are done carefully. Regular users may easily make mistakes for the sake of
convenience.
So I wonder if some pythonic methods fit into convenience modes or can
veer into dangerous modes. Spelling things out in full detail may be annoying
but generally safer.
--
https://mail.python.org/mailman/listinfo/python-list
Re: for convenience
On 22/03/2022 10.17, Chris Angelico wrote: > On Tue, 22 Mar 2022 at 08:13, Paul St George wrote: >> >> >> When I am writing code, I often do things like this: >> >> context = bpy.context # convenience >> >> then whenever I need bpy.context, I only need to write context >> >> >> Here’s my question: >> >> When I forget to use the convenient shorter form >> >> why is bpy.context not interpreted as bpy.bpy.context? >> > > I don't understand the question. When you do that "for convenience" > assignment, what you're doing is creating a local variable named > "context" which refers to the same thing that bpy.context does (or did > at the time of the assignment, but presumably you only do this when > bpy.context won't get reassigned). It has no effect on any other name. > There's no magic happening here - it's just assignment to the name > context, like anything else. > > What are you expecting to happen here? It's the way Python works. try: context = bpy.context # convenience print( id(context), id(bpy.context) ) Remember that the 'relationship' between the two is established at run-time and at the data/address 'level' - and not at compile-time. Thus "context" points to a memory location, and does not 'stand for' "bpy.context" anywhere other than in your mind. (which is why we often need to use a copy() when we want 'separate data' - see also the 'counters' Python uses to manage "garbage collection") -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: for convenience
On 21Mar2022 22:12, Paul St George wrote: >When I am writing code, I often do things like this: > >context = bpy.context # convenience > >then whenever I need bpy.context, I only need to write context > > >Here’s my question: > >When I forget to use the convenient shorter form > >why is bpy.context not interpreted as bpy.bpy.context? Because it still has its original meaning. You haven't changed the meaning of the word "context" in any position, you have simply made a module level name "context" referring to the same object to which "bpy.context" refers. So your module global namespace contains, initially, "bpy". Then you assign: context = bpy.context and now your module global namespace contains "bpy" and "context". But "bpy.context" is still what it was, because "bpy" is an object and you have done nothing to its ".context" attribute. Consider this code: class O: pass o = O() o.x = 3 x = o.x print(x) print(o.x) I expect to see "3" twice. What do you expect? "bpy" is no different to "o" - it's just a name. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: for convenience
Chris, I think you understood the context but not the premise in a sense that wasin the way Paul was thinking. His premise is way off He seems to be thinking of something like a macro concept as iscommonly used in languages like C so: #define context bpy.context That could, in such languages, use a macro preprocessor, to parse the code once to make various textual changes without any real understanding of thelanguage and produce output ready for a compiler or interpreter phase. Python has nothing really like that albeit I can think of some things as well asgimmicks and tricks that can result in less typing. As an example, you canarrange for an object embedded within another to have some way to manipulate deeper structures from a higher level meaning less typing. As you point out, in many languages, often we are dealing with an implicit pointer withvery different results. And it is not at all the same in other ways, as you againpoint out so if you later re-assign bpy to anything else, including anotherdistinct object of the same kind, the variable called "context" keeps pointingto the old part of bpy. It is not an alias that can be used and it also is a potential problemfor various reasons such as retarding garbage collection or being used laterto make a change in the wrong place. So, I ask Paul what other language than python he has used before, just out of curiosity.Many and perhaps most of use regulars here have used quite a few others and eachhas its own quirks and we have adjusted our thinking multiple times by the time welearned Python. What Paul suggests is just a convenience is more than that. It is a variablebinding with many ramifications. -Original Message- From: Chris Angelico To: python-list@python.org Sent: Mon, Mar 21, 2022 5:17 pm Subject: Re: for convenience On Tue, 22 Mar 2022 at 08:13, Paul St George wrote: > > > When I am writing code, I often do things like this: > > context = bpy.context # convenience > > then whenever I need bpy.context, I only need to write context > > > Here’s my question: > > When I forget to use the convenient shorter form > > why is bpy.context not interpreted as bpy.bpy.context? > I don't understand the question. When you do that "for convenience" assignment, what you're doing is creating a local variable named "context" which refers to the same thing that bpy.context does (or did at the time of the assignment, but presumably you only do this when bpy.context won't get reassigned). It has no effect on any other name. There's no magic happening here - it's just assignment to the name context, like anything else. What are you expecting to happen here? ChrisA -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: for convenience
No, nor did I suggest that you did. `context` is presumably an attribute in the `bpy` module, for which you are creating a `context` attribute in your module. On Mon, 2022-03-21 at 22:31 +0100, Paul St George wrote: > Hi, > I do not (knowingly) have a module called ‘context'. > > > > > > On 21 Mar 2022, at 22:24, Paul Bryan wrote: > > > > Assuming `bpy` is a module, you're creating a new attribute in your > > module, `context`, that contains a reference to the same object > > that is referenced in the `context` attribute in the `bpy` module. > > > > On Mon, 2022-03-21 at 22:12 +0100, Paul St George wrote: > > > > > > When I am writing code, I often do things like this: > > > > > > context = bpy.context # convenience > > > > > > then whenever I need bpy.context, I only need to write context > > > > > > > > > Here’s my question: > > > > > > When I forget to use the convenient shorter form > > > > > > why is bpy.context not interpreted as bpy.bpy.context? > > > > > > > > > — > > > Paul St George > > > > > > > > > > > > > > > > > > > > -- https://mail.python.org/mailman/listinfo/python-list
Re: for convenience
Hi, I do not (knowingly) have a module called ‘context'. > On 21 Mar 2022, at 22:24, Paul Bryan wrote: > > Assuming `bpy` is a module, you're creating a new attribute in your module, > `context`, that contains a reference to the same object that is referenced in > the `context` attribute in the `bpy` module. > > On Mon, 2022-03-21 at 22:12 +0100, Paul St George wrote: >> >> When I am writing code, I often do things like this: >> >> context = bpy.context # convenience >> >> then whenever I need bpy.context, I only need to write context >> >> >> Here’s my question: >> >> When I forget to use the convenient shorter form >> >> why is bpy.context not interpreted as bpy.bpy.context? >> >> >> — >> Paul St George >> >> >> >> >> > -- https://mail.python.org/mailman/listinfo/python-list
Re: for convenience
Assuming `bpy` is a module, you're creating a new attribute in your module, `context`, that contains a reference to the same object that is referenced in the `context` attribute in the `bpy` module. On Mon, 2022-03-21 at 22:12 +0100, Paul St George wrote: > > When I am writing code, I often do things like this: > > context = bpy.context # convenience > > then whenever I need bpy.context, I only need to write context > > > Here’s my question: > > When I forget to use the convenient shorter form > > why is bpy.context not interpreted as bpy.bpy.context? > > > — > Paul St George > > > > > -- https://mail.python.org/mailman/listinfo/python-list
Re: for convenience
On Tue, 22 Mar 2022 at 08:13, Paul St George wrote: > > > When I am writing code, I often do things like this: > > context = bpy.context # convenience > > then whenever I need bpy.context, I only need to write context > > > Here’s my question: > > When I forget to use the convenient shorter form > > why is bpy.context not interpreted as bpy.bpy.context? > I don't understand the question. When you do that "for convenience" assignment, what you're doing is creating a local variable named "context" which refers to the same thing that bpy.context does (or did at the time of the assignment, but presumably you only do this when bpy.context won't get reassigned). It has no effect on any other name. There's no magic happening here - it's just assignment to the name context, like anything else. What are you expecting to happen here? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
for convenience
When I am writing code, I often do things like this: context = bpy.context # convenience then whenever I need bpy.context, I only need to write context Here’s my question: When I forget to use the convenient shorter form why is bpy.context not interpreted as bpy.bpy.context? — Paul St George -- https://mail.python.org/mailman/listinfo/python-list
[ANN] Android Debug Bridge (ADB) Scripting Language For Android (SL4A) convenience library
hello, The information on ADB / SL4A is quiet overwhelming. Despite that, especially for people, not familiar with Linux, it's not an easy task to get their first program running. This library allows you to easy upload and run Python files on a Android device, without pressing any button on the Android device. After installing SL4A and Py4A on the Android device, and ADB on the hostmachine, it's just a matter of connecting the USB cable between Android device and host-PC, and run the program. One of the simplest program that will run out of the box (without touching any button on the Android device) : # * from adb_sl4a_support import ADB_Connection ADB = ADB_Connection () print ADB # Create a simple program Simple_Program = """ import android droid = android.Android (( '%s', %s )) droid.makeToast ( "Wasn't that easy?") """ % ( ADB.SL4A_Servers [-1][0], ADB.SL4A_Servers [-1][1] ) # execute the program (this will run the program from the host PC !!) exec ( Simple_Program ) # * you can find the library here: http://code.google.com/p/pylab-works/downloads/detail?name=adb_sl4a_support.py&can=2&q= cheers, Stef -- http://mail.python.org/mailman/listinfo/python-list
ANN: gui_support v1.5, a convenience library for wxPython
hello, Although I personally hate to release a new version so soon, the error reporting is so essential, that updating is a must. V1.5 changes - errors (catched by the library) will now give a normal error report - GUI preview function now available in this library gui_support is library for easy creation of GUI designs in wxPython. Brief documentation can be found here http://oase.uci.kun.nl/~mientki/data_www/pylab_works/pw_gui_support.html ( as this website will soon be moved, this docpage can always be found through the redirector http://pic.flappie.nl look under paragraph PyLab_Works | GUI_support ) Download: http://pylab-works.googlecode.com/files/Data_Python_Test_V1_5.zip cheers, Stef -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: gui_support, a convenience library for wxPython
Glenn Linderman wrote: On approximately 10/23/2008 12:59 PM, came the following characters from the keyboard of Stef Mientki: I'm no expert I thought a three-quoted string was called a "doc string", isn't that so ? No, the docstring is the first string after a function or class definition, that is displayed interactively by "help name", and used for documentation of the function or class. http://docs.python.org/reference/compound_stmts.html#function-definitions Footnotes [3] & [4] The proper name for three-quoted strings is triple-quoted string: http://docs.python.org/reference/lexical_analysis.html#id7 Often docstrings are expressed as three-quoted strings, because they want to exceed a single line. Glenn, thanks for the clarification, English is not my first language, nor is Python ;-) I already updated the webpage. cheers, Stef -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: gui_support, a convenience library for wxPython
On Oct 23, 2:14 pm, Joe Strout <[EMAIL PROTECTED]> wrote: > On Oct 23, 2008, at 11:50 AM, Stef Mientki wrote: > > > gui_support is library for easy creation of GUI designs in wxPython. > > ... > > Brief documentation can be found here > >http://oase.uci.kun.nl/~mientki/data_www/pylab_works/pw_gui_support.html > > That's neat -- thank you for making it available. I've just recently > been working through some wxPython tutorials, and wondered if there > was a simple text-based layout definition format that would let me > define my interfaces in a simpler manner. > > Your page says that the layout is defined in a docstring, but in the > sample code, it's actually just in a regular string literal. That's > nice -- it means that we could read the layout from a file, for > example, or even make a dynamic editor where we edit the layout string > in one window, and view the result in real time in another window. > > Is this layout format -- where indentation shows containment, and with > the name/type/attributes for each item on a line -- any sort of > standard, or just something you guys made up? > > Thanks very much, > - Joe You might also look at XRC: http://wiki.wxpython.org/XRCTutorial I know a number of the people on the wxPython user's group use it. Mike -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: gui_support, a convenience library for wxPython
Joe Strout wrote: On Oct 23, 2008, at 11:50 AM, Stef Mientki wrote: gui_support is library for easy creation of GUI designs in wxPython. ... Brief documentation can be found here http://oase.uci.kun.nl/~mientki/data_www/pylab_works/pw_gui_support.html That's neat -- thank you for making it available. I've just recently been working through some wxPython tutorials, and wondered if there was a simple text-based layout definition format that would let me define my interfaces in a simpler manner. Your page says that the layout is defined in a docstring, but in the sample code, it's actually just in a regular string literal. I'm no expert I thought a three-quoted string was called a "doc string", isn't that so ? That's nice -- it means that we could read the layout from a file, for example, or even make a dynamic editor where we edit the layout string in one window, and view the result in real time in another window. yes, any string will do. What you describe, my default editor is already doing it. Pressing F12 (also mentioned briefly in the doc), locates the GUI-string, gathers all the code between the GUI-string and the GUI-execute call or the GUI-Ready call and runs this part (wrapped in a default application + frame) in a separate Python machine, resulting in a full working window. And because the script is just launched, you can launch many of them and compare (small) differences in the GUI-design. Is this layout format -- where indentation shows containment, and with the name/type/attributes for each item on a line -- any sort of standard, or just something you guys made up? no standard, we just made it because in creating about 50 windows the last couple of months, we were tired of thinking about sizers and containers and containment referencing each other. So merely put this on the web, as "an idea", and I think if a number of people look at this idea, they can come up with a number of improvements. cheers, Stef Thanks very much, - Joe -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: gui_support, a convenience library for wxPython
On Oct 23, 2008, at 11:50 AM, Stef Mientki wrote: gui_support is library for easy creation of GUI designs in wxPython. ... Brief documentation can be found here http://oase.uci.kun.nl/~mientki/data_www/pylab_works/pw_gui_support.html That's neat -- thank you for making it available. I've just recently been working through some wxPython tutorials, and wondered if there was a simple text-based layout definition format that would let me define my interfaces in a simpler manner. Your page says that the layout is defined in a docstring, but in the sample code, it's actually just in a regular string literal. That's nice -- it means that we could read the layout from a file, for example, or even make a dynamic editor where we edit the layout string in one window, and view the result in real time in another window. Is this layout format -- where indentation shows containment, and with the name/type/attributes for each item on a line -- any sort of standard, or just something you guys made up? Thanks very much, - Joe -- http://mail.python.org/mailman/listinfo/python-list
ANN: gui_support, a convenience library for wxPython
hello, gui_support is library for easy creation of GUI designs in wxPython. Although it's quit stable, it's part of a larger project and therefor has a lot of dependencies, but these can easily be removed. Warning: Although this library might be very attractive to newbies, the use of this library will prevent you from learning some of the basics of GUI, specially of containers / sizers in wxPython. Brief documentation can be found here http://oase.uci.kun.nl/~mientki/data_www/pylab_works/pw_gui_support.html ( as this website will soon be moved, this docpage can always be found through the redirector http://pic.flappie.nl look under paragraph PyLab_Works | GUI_support ) Download: http://pylab-works.googlecode.com/files/Data_Python_Test.zip cheers, Stef -- http://mail.python.org/mailman/listinfo/python-list
The Convenience of Online Learning. The Benefits of a Respected Degree.Try Ellis College for Free.
A fully accredited extension of The New York Institute of Technology (NYIT), Ellis College gives you the prestige of earning your Bachelor's Degree from a respected university with the convenience of learning online on your own schedule. Whether you're looking to begin a new career or advance an existing one, Ellis offers an array of flexible online Undergraduate Degree programs to help you achieve your goal. Fully Accredited. Esteemed Faculty. An academic division of the New York Institute of Technology, Ellis College is accredited by the Middle States Commission on Higher Education, one of six regional accrediting bodies for higher education recognized by the U.S. Secretary of Education. Every Ellis instructor holds a Ph.D. or Masters Degree in their subject matter, with nearly half of all teaching faculty holding a Doctorate or other terminal degree. Get a free guest pass to Ellis College and experience a fully- accredited online college like no other. You'll have access to Ellis CourseBites™ mini-courses, educational Webcasts, and our interactive course demonstrations. Getting started is easy! Just fill out the form to get your free pass. Click Here:http://www.anrdoezrs.net/ot114fv2rz1GJKJOOOIGIHLOJLKI -- http://mail.python.org/mailman/listinfo/python-list
The Convenience of Online Learning. The Benefits of a Respected Degree.Try Ellis College for Free.
A fully accredited extension of The New York Institute of Technology (NYIT), Ellis College gives you the prestige of earning your Bachelor's Degree from a respected university with the convenience of learning online on your own schedule. Whether you're looking to begin a new career or advance an existing one, Ellis offers an array of flexible online Undergraduate Degree programs to help you achieve your goal. Fully Accredited. Esteemed Faculty. An academic division of the New York Institute of Technology, Ellis College is accredited by the Middle States Commission on Higher Education, one of six regional accrediting bodies for higher education recognized by the U.S. Secretary of Education. Every Ellis instructor holds a Ph.D. or Masters Degree in their subject matter, with nearly half of all teaching faculty holding a Doctorate or other terminal degree. Get a free guest pass to Ellis College and experience a fully- accredited online college like no other. You'll have access to Ellis CourseBites™ mini-courses, educational Webcasts, and our interactive course demonstrations. Getting started is easy! Just fill out the form to get your free pass. Click Here:http://www.anrdoezrs.net/ot114fv2rz1GJKJOOOIGIHLOJLKI -- http://mail.python.org/mailman/listinfo/python-list
