Re: Dict when defining not returning multi value key error
Marko Rauhamaa :
> Important systems absolutely rely on the fact that the hashes can be
> used for identification. They are not just checksums. They are not
> double-checked with bit-to-bit comparisons of the actual data.
And in fact, you can use the principle in Python:
class Thingy:
def __init__(self, ...):
...
self.stronghash = self.compute_strong_hash()
self.hash = struct.unpack("Q", self.stronghash[:8])[0]
def __hash__(self):
return self.hash
def __eq__(self, other):
try:
return self.stronghash == other.stronghash
except AttributeError:
return False
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Re: 3 Suggestions to Make Python Easier For Children
Mark Summerfield : > Suggestion #1: Make IDLE start in the user's home directory. > > Suggestion #2: Make all the turtle examples begin "from turtle import > *" so no leading turtle. is needed in the examples. > > Suggestion #3: Make object(key=value, ...) legal and equiv of > types.SimpleNamespace(key=value, ...). Great suggestions for adults as well. Expanding #3: >>> o = object() >>> o.x = 3 Traceback (most recent call last): File "", line 1, in AttributeError: 'object' object has no attribute 'x' Why? Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On Sat, Aug 02, Gregory Ewing wrote: > MacOSX doesn't currently have an automatic dependency > manager, but if it did, things would still be a lot neater > and tidier than they are in Linux or Windows, where what > is conceptually a single object (a package) gets split up > and its parts scattered around several obscure locations. How does "a package" differ? Its "a package" here and there. Just use the correct tools to inspect "a package", like 'rpm -qliv $package' to see what "a package" is all about. Olaf -- https://mail.python.org/mailman/listinfo/python-list
Re: 3 Suggestions to Make Python Easier For Children
On Saturday, 2 August 2014 08:14:08 UTC+1, Marko Rauhamaa wrote: > Mark Summerfield: > > > Suggestion #1: Make IDLE start in the user's home directory. > > > Suggestion #2: Make all the turtle examples begin "from turtle import > > *" so no leading turtle. is needed in the examples. > > > > Suggestion #3: Make object(key=value, ...) legal and equiv of > > types.SimpleNamespace(key=value, ...). > > Great suggestions for adults as well. > > Expanding #3: > >>>> o = object() >>>> o.x = 3 >Traceback (most recent call last): > File "", line 1, in >AttributeError: 'object' object has no attribute 'x' > > Why? > > Marko object() returns a minimal featureless object with no dictionary (no __dict__ attribute). This makes sense for efficiency since not all objects need a dictionary. What I'm suggesting is that _in addition_ to the existing behavior, a new behavior is introduced whereby object() called with keyword arguments creates a types.SimpleNamespace object (i.e., a basic object that has a dictionary initialized by the keyword arguments). Mark. -- https://mail.python.org/mailman/listinfo/python-list
Re: eval [was Re: dict to boolean expression, how to?]
Steven D'Aprano wrote:
> On Fri, 01 Aug 2014 17:44:27 +0200, Peter Otten wrote:
> [...]
>>> bool = ((df['a'] == 1) & (df['A'] == 0) |
>>> (df['b'] == 1) & (df['B'] == 0) |
>>> (df['c'] == 1) & (df['C'] == 0))
>>
>> This is how it might look without eval():
>>
>> #untested
>> result = functools.reduce(operator.or_, ((v == 1) & (df[k.upper()] == 0)
>> for k, v in df.items() if k.islower()))
>
> For those who agree with Guido that reduce makes code unreadable:
>
> result = True
> for key in df:
> if key.islower():
> result = result or (df[key] == 1 and df[key.upper()] == 0)
I cheated a bit and gave the solution that the OP was unlikely to come up
with ;)
> Or if you insist on a single expression:
>
> result = any(df[k] == 1 and df[k.upper()] == 0 for k in df if k.islower())
>
>
>> And here is an eval-based solution:
>>
>> # untested
>> expr = "|".join(
>> "((df[{}] == 1) | (df[{}] == 0))".format(c, c.upper()) for c in df
>> is c.islower())
>> result = eval(expr)
>
> I really don't believe that there is any benefit to that in readability,
> power, flexibility, or performance.
You can put in a print(expr) to verify that it's identical to the original
spelt out expression.
> Also, you're using bitwise operators
> instead of shortcut bool operators. Any reason why?
Since he started the thread Alex has moved the goal posts a bit and added
that he is using a pandas DataFrame. That works much like a numpy array. So:
>>> df
a Ab B c C
0 1 4 100 1000 7 14
1 2 1 200 2000 21 28
2 1 0 300 3000 35 42
>>> df["a"] == 1
0 True
1False
2 True
Name: a, dtype: bool
>>> (df["a"] == 1) and (df["A"] == 0)
Traceback (most recent call last):
File "", line 1, in
ValueError: The truth value of an array with more than one element is
ambiguous. Use a.any() or a.all()
>>> (df["a"] == 1) & (df["A"] == 0)
0False
1False
2 True
dtype: bool
--
https://mail.python.org/mailman/listinfo/python-list
Re: 3 Suggestions to Make Python Easier For Children
On 02/08/2014 07:45, Mark Summerfield wrote:
Last week I spent a couple of days teaching two children (10 and 13 -- too big
an age gap!) how to do some turtle graphics with Python. Neither had programmed
Python before -- one is a Minecraft ace and the other had done Scratch.
Suggestion #1: Make IDLE start in the user's home directory.
Entirely agree. Please raise an enhancement request on the bug tracker
if there isn't already one.
Suggestion #2: Make all the turtle examples begin "from turtle import *" so no
leading turtle. is needed in the examples.
I'm not so sure about this, but raise an enhancement request and see
what happens. Worst case it gets rejected, best case it gets accepted,
implemented and patch applied.
Suggestion #3: Make object(key=value, ...) legal and equiv of
types.SimpleNamespace(key=value, ...).
Haven't the faintest idea and too lazy to find out :) I suggest follow
advice from #2.
Explanation & Rationale (long):
They both had Windows laptops and so we began by installing Python. They didn't
know if they had 32- or 64-bit computers but it didn't matter, the installs
just worked. One child had no problem but the other ended up on the Download
page which lists all the possible Windows downloads; so we had to go back and
start again.
We discovered that IDLE's working directory is C:\Python34 -- surely this is the wrong working
directory for 99% of normal users and for 100% of beginners? Naturally they saved all their .py
files there until I realised. And then when I got them to create a new directory for their own
files ("Python" and "pie_thon") and dragged them across they also managed to
move python.exe and pythonw.exe.
Couldn't IDLE start in the home directory?
The turtle package is quite nice and there is a very short but dramatic colored
star example at the start of the docs. There really ought to be a little
gallery of similar examples, including circle, polygon, and star (yes I know
circle and polygon are built in but it is nice for children to see a simple
implementation), and of course a few more -- but not any that compose shapes
(e.g., face and house), since one would want them to learn how to compose
themselves.
Making them type turtle.this and turtle.that would be torture, so we began
every file with
from turtle import *
I wish the doc examples did the same. (For randint we did from random import
randint since only the one function was needed.)
I stuck to pure procedural programming since OO would have been too much
cognitive load to add given the time. I did make sure that once they'd created
something (e.g., a face), they then put it inside a function.
However, when it came to making a game ("hit the hippo") we needed to maintain
some state that several functions could access. (I had to gloss over that we were doing
higher order programming! -- e.g. onscreenclick(goto) etc.) What I wanted to write was
this:
state = object(moving=True, score=0) # Illegal!
...
state.moving = False # etc.
But was forced to do this:
state = {'moving': True, 'score': 0}
...
state['moving'] = False # so they get confused between {} and []
There is an alternative:
from types import SimpleNamespace
state = SimpleNamespace(moving=True, score=0)
...
state.moving = False # etc.
But I felt that explaining what a namespace was would be too much -- remember
they're having problems remembering to put () at the end of function calls etc.
It would be nicer if object() acted as it does now but object(key=value,...)
behaved like types.SimpleNamespace.
Finally I believe there's a very strong chance that of of this will be
taken on board. I've noticed activity on the bugtracker recently
regarding turtle, GSOC student maybe?
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
--
https://mail.python.org/mailman/listinfo/python-list
Re: eval [was Re: dict to boolean expression, how to?]
On 02/08/2014 03:59, Steven D'Aprano wrote: My refactoring, with the bare minimum use of exec necessary: https://code.activestate.com/recipes/578918-yet-another-namedtuple/ FTR I get the feed of new recipes from gwene.com.activestate.code.feeds.recipes.langs.python from news.gmane.org. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: 3 Suggestions to Make Python Easier For Children
Mark Summerfield : > object() returns a minimal featureless object with no dictionary (no > __dict__ attribute). This makes sense for efficiency since not all > objects need a dictionary. __setattr__ could create __dict__ belatedly. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: 3 Suggestions to Make Python Easier For Children
On Saturday, 2 August 2014 08:46:04 UTC+1, Mark Lawrence wrote: > On 02/08/2014 07:45, Mark Summerfield wrote: > [snip] > > > Suggestion #1: Make IDLE start in the user's home directory. > > Entirely agree. Please raise an enhancement request on the bug tracker > if there isn't already one. Done: http://bugs.python.org/issue22121 > > Suggestion #2: Make all the turtle examples begin "from turtle import *" so > > no leading turtle. is needed in the examples. > > I'm not so sure about this, but raise an enhancement request and see > what happens. Worst case it gets rejected, best case it gets accepted, > implemented and patch applied. Done: http://bugs.python.org/issue22122 > > Suggestion #3: Make object(key=value, ...) legal and equiv of > > types.SimpleNamespace(key=value, ...). > > Haven't the faintest idea and too lazy to find out :) I suggest follow > advice from #2. Done: http://bugs.python.org/issue22123 Mark. -- https://mail.python.org/mailman/listinfo/python-list
Re: Bug with help (was Re: Getting a list of all modules)
Akira Li wrote:
>>> Look at how `help('modules')` is implemented. Though it crashes on my
>>> system.
>> Have you reported this at bugs.python.org or is there already an issue
>> for the problem that you see?
>It is this issue for python2.7:
>https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/896836
>
>python3 doesn't crash with currently installed packages.
Python 2.7 on Windows XP Sp2 doesn't crash with this. So it seems to
be a python<->OS-problem.
Regards,
H.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Dict when defining not returning multi value key error
On Sat, Aug 2, 2014 at 4:41 PM, Marko Rauhamaa wrote: > I don't know why you way hg and git have no threat models. A great deal > of damage could be inflicted if you could sneak malicious edits into > version control systems without altering the hash. You would have to somehow push that change into someone else's repository. I'm not sure how you'd go about doing that without actually having a commit, which will be kinda visible. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
Chris Angelico wrote: The "easier target for the mouse" argument is valuable ONLY when you use the mouse to access the menu bar. If you use the keyboard (and take advantage of mnemonic letters), it's much more useful to have the menu bar attached to its window. Seems to me that if you use the keyboard for everything, it doesn't matter where the menu bar is. Unless you're talking about the way you can use the keyboard to make menus drop down in Windows... but that's not the way Mac menu shortcuts work. The menu doesn't visually drop down when you invoke a Mac menu command with the keyboard. In the rare case of an app that runs without any windows, incidentally, how do you tell the system that you want that app's menu bar instead of (say) Finder, which comes up when you click on the desktop? In classic MacOS, there was a menu of running applications in the top right corner. In MacOSX, you click on the app's icon in the dock. Also, while completely windowless applications might be rare, it's not rare for an app to have some commands that pertain to the app itself, and not to any particular window, e.g. "New". It's more logical for those to appear in a user interface element that's not tied to a window. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
Olaf Hering wrote: How does "a package" differ? Its "a package" here and there. Just use the correct tools to inspect "a package", like 'rpm -qliv $package' to see what "a package" is all about. Splitting the package up creates a problem, which you then need to invent a special tool to solve. Seems to me it's simpler not to create the problem in the first place. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Dict when defining not returning multi value key error
On 8/1/14 10:30 AM, Ian Kelly wrote:
On Thu, Jul 31, 2014 at 9:28 PM, Terry Reedy wrote:
On 7/31/2014 5:15 PM, Ian Kelly wrote:
On Thu, Jul 31, 2014 at 5:24 AM, Dilu Sasidharan
wrote:
Hi,
I am wondering why the dictionary in python not returning multi value key
error when i define something like
p = {'k':"value0",'k':"value1"}
key is string immutable and sometimes shares same id.
also if the key is immutable and have different ids.
like
p = {'1':"value0",'1.0':"value1"}
In this latter case note that '1' and '1.0' are not equal, so this
will simply result in two separate entries in the dict anyway.
Dilu presumably meant
p = {1:"value0", 1.0:"value1"}
p
{1: 'value1'}
Maybe, but it was explicitly stated that the keys were strings.
You are right, my mistake. Apologies.
--
Ned Batchelder, http://nedbatchelder.com
--
https://mail.python.org/mailman/listinfo/python-list
Re: Bug with help (was Re: Getting a list of all modules)
On 2014-08-02 09:33, Heinz Schmitz wrote:
Akira Li wrote:
Look at how `help('modules')` is implemented. Though it crashes on my
system.
Have you reported this at bugs.python.org or is there already an issue
for the problem that you see?
It is this issue for python2.7:
https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/896836
python3 doesn't crash with currently installed packages.
Python 2.7 on Windows XP Sp2 doesn't crash with this. So it seems to
be a python<->OS-problem.
Well, it's just that `help('modules')` imports every module in the calling
process (at least in Python 2.7; I haven't checked Python 3). Some extension
modules conflict with each other and cause a crash when both are imported
together. It's possible that you just don't have such modules installed. While
the proximate cause of the crash is in the 3rd party modules, Python could (and
maybe Python 3 does) import each module in a separate subprocess and collect the
information that way.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On Sat, Aug 2, 2014 at 9:33 PM, Gregory Ewing wrote: > Chris Angelico wrote: >> >> The "easier target for the mouse" argument is valuable ONLY >> when you use the mouse to access the menu bar. If you use the keyboard >> (and take advantage of mnemonic letters), it's much more useful to >> have the menu bar attached to its window. > > > Seems to me that if you use the keyboard for everything, > it doesn't matter where the menu bar is. Unless you're > talking about the way you can use the keyboard to make > menus drop down in Windows... but that's not the way > Mac menu shortcuts work. The menu doesn't visually drop > down when you invoke a Mac menu command with the keyboard. There are two forms of shortcut key. One is a direct-action keystroke that immediately does the same thing that you can do using the menus (say, Ctrl-O is the same as File... Open). With those, the menu is completely unnecessary, except as a list of available keystrokes; it could just as easily be a help screen that says "Press Ctrl-O to open a file", so the menu's actual location is quite arbitrary. Downside: There's only so many keystrokes available, and not all of them have memorable meanings. It's usually best to keep this to the few most common functions (opening a file, yes, but not "reinterpret this file as ISO-8859-3", unless you make that configurable per user). But the other form, usually described as menu mnemonics, is where you press Alt-F to bring up the _File menu, and then O to activate _Open. (In OS/2, those would be ~File and ~Open; in GTK, the mnemonic is preceded by an underscore. Windows 3.1 used an ampersand, and I believe Win32 does the same thing. It's a little awkward when you have an invoicing screen and you put something like "P&O Shipping" as your customer name, and suddenly Alt-O takes you someplace different. The tilde has the advantage that it doesn't often come up accidentally; the underscore makes sense because the mnemonic is underlined; I have no idea why an ampersand should be used. But I digress.) When you work this way, you aren't grabbing the mouse, so the advantage of not needing to aim so carefully doesn't exist; but if the menu comes up right near where your eyes are already focused, you need to move _them_ less distance - and that means you can focus on the menu more quickly, plus it emphasizes that the visual change (opening the menu) occurred in your current program, not in something else. In Xfce, I can press Alt-F1 to open up the main Applications Menu. That's at the top of the screen (in fact, top left corner), so it gets the "throw the mouse" benefit; I think I use the mouse with that a lot more often than I use the mouse with a program's own menu, because there's more likely to be something unusual in there. If I install a new piece of software, I have to figure out where it's landed in the menu; but Gypsum's four menus aren't changing unexpectedly, so I'm happy using Alt-O, V to open up Advanced Options. >> In the rare case of an app >> that runs without any windows, incidentally, how do you tell the >> system that you want that app's menu bar instead of (say) Finder, >> which comes up when you click on the desktop? > > In classic MacOS, there was a menu of running applications > in the top right corner. In MacOSX, you click on the app's > icon in the dock. Okay. So you need to first click on something in the dock - that's the thing down the bottom of the screen, right? - and then go all the way up to the top of the screen to use its menu bar. I think I'd much rather have a popup menu - right-click the program's dock icon and get the menu right there where the mouse already is. Oh wait, that requires people to understand more than a single mouse button, so it's contrary to Mac philosophy :) > Also, while completely windowless applications might be > rare, it's not rare for an app to have some commands that > pertain to the app itself, and not to any particular > window, e.g. "New". It's more logical for those to appear > in a user interface element that's not tied to a window. Sure, but those elements are usually rare enough that they can be stuck on the window anyway. Audacity has a "New" that opens up a new window, and it's slightly surprising the first couple of times, but after that you get used to it. It's not a big enough issue to warrant a change of UI. It is an issue, yes, but I wouldn't warp anything around it any more than I'd warp my UI around the possibility of a user having no screen or keyboard and is using the mouse blind. Sure it happens (I've done it, and I know what I could code to make it easier!), but not often. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On 2014-08-02 01:00, Gregory Ewing wrote: MRAB wrote: [snip] And don't mention the menu bar across the top, separated from the window to which it belonged. That seems to be a matter of taste. There are some advantages to the menu-bar-at-top model. It's an easier target to hit, because you can just flick the mouse up to the top. It only takes up space once, instead of once per window. It makes it possible for an app to be running without having any windows, and still be able to interact with it. RISC OS didn't have a menu bar at the top of each window either; its menus were all pop-up. You didn't have to keep flicking the mouse at all! -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
In article , Gregory Ewing wrote: > > And don't mention the menu bar across the top, separated from the > > window to which it belonged. > > That seems to be a matter of taste. There are some > advantages to the menu-bar-at-top model. It's an easier > target to hit, because you can just flick the mouse up > to the top. It only takes up space once, instead of > once per window. It makes it possible for an app to > be running without having any windows, and still be > able to interact with it. In the old days, we had really small screens (the original Mac had a 9 inch screen with 512 x 342 resolution). Most application windows filled most of the screen, so there really wasn't much difference between per-desktop and per-window menu bars. These days, I'm running multiple 24 inch monitors. The single menu bar paradigm starts to break down in an environment like that. I find I tend to put the few windows I'm actively using near the top of my primary screen (the one with the menu bar), and use the second screen to hold windows I'm not interacting with much. -- https://mail.python.org/mailman/listinfo/python-list
Tkinter grid autosize help
So i have a basic calculator program and i have a label that i want to go across the top to show the numbers and stuff like on a normal calculator. The only way i can make the buttons look neat and then when i keep pressing one the label gets larger and then half the buttons move out of the screen. I cant seem to fix this i have tried columnspan, columnconfigure and heaps of other stuff and non works it always expands. is there a way i can stop the grid from expanding? -- https://mail.python.org/mailman/listinfo/python-list
Re: Tkinter grid autosize help
On 2014-08-02 15:38, Nicholas Cannon wrote: So i have a basic calculator program and i have a label that i want to go across the top to show the numbers and stuff like on a normal calculator. The only way i can make the buttons look neat and then when i keep pressing one the label gets larger and then half the buttons move out of the screen. I cant seem to fix this i have tried columnspan, columnconfigure and heaps of other stuff and non works it always expands. is there a way i can stop the grid from expanding? You haven't provided any code, so it's not possible to say where you're going wrong! -- https://mail.python.org/mailman/listinfo/python-list
Re: 3 Suggestions to Make Python Easier For Children
Marko Rauhamaa wrote: > Expanding #3: > >>>> o = object() >>>> o.x = 3 >Traceback (most recent call last): > File "", line 1, in >AttributeError: 'object' object has no attribute 'x' > > Why? There are two intended uses for object and its instances: - as the base class for all other classes; - instances can be used as featureless sentinel objects where only identity matters. If you need instances which carry state, then object is the wrong class. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: 3 Suggestions to Make Python Easier For Children
Marko Rauhamaa wrote: > Mark Summerfield : > >> object() returns a minimal featureless object with no dictionary (no >> __dict__ attribute). This makes sense for efficiency since not all >> objects need a dictionary. > > __setattr__ could create __dict__ belatedly. Are we designing Son Of PHP, or a sensible language? *wink* If object.__setattr__ did this, then we're left with two equally horrible choices: - only object works this way, not subclasses of object, which violates the Liskov substitution principle; - all instances, of every type, work this way, which causes chaos and destruction everywhere. Some of the consequences: * Classes with __slots__ will stop working as expected. * Immutable instances will no longer be immutable, since they can have mutable state. * The CPython interpreter shares immutable built-ins like ints across multiple processes. Either CPython would have to stop doing this (increasing memory requirements significantly), or one process could reach across to another and mutate its ints. Well, perhaps not *equally* horrible. Compared to the second alternative, violating the LSP seems relatively benign. There's also the implementation difficulty that instance.__dict__ is kept in a slot (obviously, since it cannot be stored in the per instance __dict__ !), which means that you cannot easily or practically expect to dynamically add/or delete it from instances. Now I'm sure with sufficient effort we could do so, but that's a lot of effort for negligible (or even negative) gain. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Tkinter grid autosize help
On 02/08/2014 15:38, Nicholas Cannon wrote: So i have a basic calculator program and i have a label that i want to go across the top to show the numbers and stuff like on a normal calculator. The only way i can make the buttons look neat and then when i keep pressing one the label gets larger and then half the buttons move out of the screen. I cant seem to fix this i have tried columnspan, columnconfigure and heaps of other stuff and non works it always expands. is there a way i can stop the grid from expanding? Please help us to help you by reading and actioning this http://sscce.org/, thanks. p.s. being British I must point out that I is spelt I and not i :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: 3 Suggestions to Make Python Easier For Children
Steven D'Aprano : > Marko Rauhamaa wrote: >> __setattr__ could create __dict__ belatedly. > > Are we designing Son Of PHP, or a sensible language? *wink* > > If object.__setattr__ did this, then we're left with two equally > horrible choices: Not a huge issue. Only mildly annoying to have to create: class Object: pass in every application. And the newest Python releases let you replace that with: import types Object = types.SimpleNamespace Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: 3 Suggestions to Make Python Easier For Children
On 02/08/2014 18:07, Marko Rauhamaa wrote: Steven D'Aprano : Marko Rauhamaa wrote: __setattr__ could create __dict__ belatedly. Are we designing Son Of PHP, or a sensible language? *wink* If object.__setattr__ did this, then we're left with two equally horrible choices: Not a huge issue. Only mildly annoying to have to create: class Object: pass in every application. And the newest Python releases let you replace that with: import types Object = types.SimpleNamespace Marko With the latter being part of suggestion #3 in the original post. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Bug with help (was Re: Getting a list of all modules)
On 8/2/2014 8:13 AM, Robert Kern wrote:
On 2014-08-02 09:33, Heinz Schmitz wrote:
Akira Li wrote:
Look at how `help('modules')` is implemented. Though it crashes on my
system.
Have you reported this at bugs.python.org or is there already an issue
for the problem that you see?
It is this issue for python2.7:
https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/896836
python3 doesn't crash with currently installed packages.
Python 2.7 on Windows XP Sp2 doesn't crash with this. So it seems to
be a python<->OS-problem.
It is a local system problem.
Well, it's just that `help('modules')` imports every module in the
calling process (at least in Python 2.7; I haven't checked Python 3).
Some extension modules conflict with each other and cause a crash when
both are imported together. It's possible that you just don't have such
modules installed. While the proximate cause of the crash is in the 3rd
party modules, Python could (and maybe Python 3 does) import each module
in a separate subprocess and collect the information that way.
That would slow down help('modules') much more. The suggestion in
http://bugs.python.org/issue12902
"help("modules") executes module code"
is that help() should instead parse the module to get the docstring.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: 3 Suggestions to Make Python Easier For Children
Mark Lawrence : > On 02/08/2014 18:07, Marko Rauhamaa wrote: >> And the newest Python releases let you replace that with: >> >> import types >> Object = types.SimpleNamespace > > With the latter being part of suggestion #3 in the original post. Not quite. Even though Sugg. #3 would allow me to do: object(x=3) this wouldn't work: object().x = 3 However, these would continue working: types.SimpleNamespace(x=3) types.SimpleNamespace().x = 3 Also, assuming Sugg. #3, would this work: object(x=3).y = 2 as this does: types.SimpleNamespace(x=3).y = 2 Marko -- https://mail.python.org/mailman/listinfo/python-list
Correct type for a simple “bag of attributes” namespace object (was: 3 Suggestions to Make Python Easier For Children)
Steven D'Aprano writes: > If you need instances which carry state, then object is the wrong > class. Right. The ‘types’ module provides a SimpleNamespace class for the common “bag of attributes” use case:: >>> import types >>> foo = types.SimpleNamespace() >>> foo.x = 3 >>> foo namespace(x=3) https://docs.python.org/3/library/types.html#types.SimpleNamespace> -- \ “Nothing is more sacred than the facts.” —Sam Harris, _The End | `\ of Faith_, 2004 | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Correct type for a simple "bag of attributes" namespace object (was: 3 Suggestions to Make Python Easier For Children)
On Saturday, 2 August 2014 20:58:59 UTC+1, Ben Finney wrote: > Steven D'Aprano writes: > > > If you need instances which carry state, then object is the wrong > > class. Fair enough. > Right. The 'types' module provides a SimpleNamespace class for the > common "bag of attributes" use case:: > > >>> import types > >>> foo = types.SimpleNamespace() > >>> foo.x = 3 > >>> foo > namespace(x=3) This is too much for children (& beginners). But perhaps what I should be asking for is for a new built-in that does what types.SimpleNamespace() does, so that without any import you can write, say, foo = namespace(a=1, b=2) # or bar = namespace() bar.a = 1 where under the hood namespace has the same behavior as types.SimpleNamespace(). Naturally, I understand that adding a new name is a big deal and may be too much to ask for beginners. -- https://mail.python.org/mailman/listinfo/python-list
Re: Correct type for a simple "bag of attributes" namespace object (was: 3 Suggestions to Make Python Easier For Children)
On Sun, Aug 3, 2014 at 6:46 AM, Mark Summerfield wrote: > But perhaps what I should be asking for is for a new built-in that does what > types.SimpleNamespace() does, so that without any import you can write, say, > > foo = namespace(a=1, b=2) > # or > bar = namespace() > bar.a = 1 > > where under the hood namespace has the same behavior as > types.SimpleNamespace(). > > Naturally, I understand that adding a new name is a big deal and may be too > much to ask for beginners. This is where you might want to consider putting some imports into site.py. That way, you can set up your own customized Python, without waiting for changes to be approved for core (which they probably won't - new builtins have a high requirement for necessity, not just "I don't want to have to type import"). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Getting a list of all modules
On Friday, 1 August 2014 16:41:41 UTC+1, Steven D'Aprano wrote: > On Fri, 01 Aug 2014 14:39:09 +0100, Robert Kern wrote: > > > > > Take a look at what has already been implemented in IPython: > > > > > > https://github.com/ipython/ipython/blob/master/IPython/core/ > > completerlib.py#L208 > > > > > > Awesome! Thank you! > > > > > > -- > > Steven Also this, possibly: https://github.com/davidhalter/jedi Jon N -- https://mail.python.org/mailman/listinfo/python-list
Re: Correct type for a simple "bag of attributes" namespace object
On 02/08/2014 22:05, Chris Angelico wrote: On Sun, Aug 3, 2014 at 6:46 AM, Mark Summerfield wrote: But perhaps what I should be asking for is for a new built-in that does what types.SimpleNamespace() does, so that without any import you can write, say, foo = namespace(a=1, b=2) # or bar = namespace() bar.a = 1 where under the hood namespace has the same behavior as types.SimpleNamespace(). Naturally, I understand that adding a new name is a big deal and may be too much to ask for beginners. This is where you might want to consider putting some imports into site.py. That way, you can set up your own customized Python, without waiting for changes to be approved for core (which they probably won't - new builtins have a high requirement for necessity, not just "I don't want to have to type import"). ChrisA I'd forgotten all about site.py so went to the 3.4.1 docs and found "Deprecated since version 3.4: Support for the “site-python” directory will be removed in 3.5.". Plan B? :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Getting a list of all modules
On 02/08/2014 22:13, [email protected] wrote: On Friday, 1 August 2014 16:41:41 UTC+1, Steven D'Aprano wrote: On Fri, 01 Aug 2014 14:39:09 +0100, Robert Kern wrote: Take a look at what has already been implemented in IPython: https://github.com/ipython/ipython/blob/master/IPython/core/ completerlib.py#L208 Awesome! Thank you! -- Steven Also this, possibly: https://github.com/davidhalter/jedi Jon N Would you please read and action this https://wiki.python.org/moin/GoogleGroupsPython to prevent us seeing the double line spacing above, thanks. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Correct type for a simple "bag of attributes" namespace object
On Sun, Aug 3, 2014 at 7:16 AM, Mark Lawrence wrote: > I'd forgotten all about site.py so went to the 3.4.1 docs and found > "Deprecated since version 3.4: Support for the “site-python” directory will > be removed in 3.5.". > > Plan B? :) Oh. Hrm. I've no idea... but I'm sure there'll be a way to say "execute this at the beginning of an interactive session". Dig in the docs. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Correct type for a simple "bag of attributes" namespace object
On 02/08/2014 22:16, Mark Lawrence wrote: On 02/08/2014 22:05, Chris Angelico wrote: On Sun, Aug 3, 2014 at 6:46 AM, Mark Summerfield wrote: But perhaps what I should be asking for is for a new built-in that does what types.SimpleNamespace() does, so that without any import you can write, say, foo = namespace(a=1, b=2) # or bar = namespace() bar.a = 1 where under the hood namespace has the same behavior as types.SimpleNamespace(). Naturally, I understand that adding a new name is a big deal and may be too much to ask for beginners. This is where you might want to consider putting some imports into site.py. That way, you can set up your own customized Python, without waiting for changes to be approved for core (which they probably won't - new builtins have a high requirement for necessity, not just "I don't want to have to type import"). ChrisA I'd forgotten all about site.py so went to the 3.4.1 docs and found "Deprecated since version 3.4: Support for the “site-python” directory will be removed in 3.5.". Plan B? :) Plan B is revert to plan A, I didn't read things anything like thoroughly enough, sorry about the noise :( -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Python Programing for the Absoulte Beginner
https://www.google.com/webhp?hl=en&tab=ww&gws_rd=ssl#hl=en&q=python+programing+for+the+absolute+beginner There is a book listed as a PDF. When I try the first example of print "Game Over" I get a syntax error. I have tried running the command line and the GUI. I get the feeling there is something else I need to run. http://imgur.com/RH3yczP -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Programing for the Absoulte Beginner
On Sun, Aug 3, 2014 at 8:13 AM, Seymore4Head
wrote:
> https://www.google.com/webhp?hl=en&tab=ww&gws_rd=ssl#hl=en&q=python+programing+for+the+absolute+beginner
>
> There is a book listed as a PDF.
>
> When I try the first example of print "Game Over" I get a syntax
> error.
>
> I have tried running the command line and the GUI. I get the feeling
> there is something else I need to run.
>
> http://imgur.com/RH3yczP
Try this instead:
print("Game Over")
You're looking at a Python 2 book, and you're running Python 3. I
would recommend instead getting a Python 3 tutorial:
https://docs.python.org/3/tutorial/
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python Programing for the Absoulte Beginner
On 02/08/2014 23:13, Seymore4Head wrote:
https://www.google.com/webhp?hl=en&tab=ww&gws_rd=ssl#hl=en&q=python+programing+for+the+absolute+beginner
There is a book listed as a PDF.
When I try the first example of print "Game Over" I get a syntax
error.
I have tried running the command line and the GUI. I get the feeling
there is something else I need to run.
http://imgur.com/RH3yczP
If the book is for Python 2 and you have 3.3 it should be print("Game Over")
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python Programing for the Absoulte Beginner
On Sun, 3 Aug 2014 08:30:15 +1000, Chris Angelico
wrote:
>On Sun, Aug 3, 2014 at 8:13 AM, Seymore4Head
> wrote:
>> https://www.google.com/webhp?hl=en&tab=ww&gws_rd=ssl#hl=en&q=python+programing+for+the+absolute+beginner
>>
>> There is a book listed as a PDF.
>>
>> When I try the first example of print "Game Over" I get a syntax
>> error.
>>
>> I have tried running the command line and the GUI. I get the feeling
>> there is something else I need to run.
>>
>> http://imgur.com/RH3yczP
>
>Try this instead:
>
>print("Game Over")
>
>You're looking at a Python 2 book, and you're running Python 3. I
>would recommend instead getting a Python 3 tutorial:
>
>https://docs.python.org/3/tutorial/
>
>ChrisA
Thanks.
I was reading a little in this group and someone had recommended
trying codecademy.com
That seems to be a pretty good way to start so far.
I will also try your link.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python Programing for the Absoulte Beginner
On Sat, 02 Aug 2014 23:31:35 +0100, Mark Lawrence
wrote:
>On 02/08/2014 23:13, Seymore4Head wrote:
>> https://www.google.com/webhp?hl=en&tab=ww&gws_rd=ssl#hl=en&q=python+programing+for+the+absolute+beginner
>>
>> There is a book listed as a PDF.
>>
>> When I try the first example of print "Game Over" I get a syntax
>> error.
>>
>> I have tried running the command line and the GUI. I get the feeling
>> there is something else I need to run.
>>
>> http://imgur.com/RH3yczP
>>
>
>If the book is for Python 2 and you have 3.3 it should be print("Game Over")
Thanks
I am sure they had a good reason to add using 2 more characters for
doing the same job.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Tkinter grid autosize help
On Saturday, August 2, 2014 10:38:28 PM UTC+8, Nicholas Cannon wrote:
> So i have a basic calculator program and i have a label that i want to go
> across the top to show the numbers and stuff like on a normal calculator. The
> only way i can make the buttons look neat and then when i keep pressing one
> the label gets larger and then half the buttons move out of the screen. I
> cant seem to fix this i have tried columnspan, columnconfigure and heaps of
> other stuff and non works it always expands. is there a way i can stop the
> grid from expanding?
ok here is the code:
#window setup
main = Tk()
main.title('Calculator')
main.geometry('300x350')
main.resizable()
app = Frame(main)
app.grid()
app.columnconfigure(0, weight=500)
app.columnconfigure(1, weight=500)
#number view label
number = ' '
numberView = Label(app, text= number)
numberView.grid(row=0, column=0, columnspan=100)
#Num Pad Buttons below
num1 = '1'
button1 = Button(app, text='1', command= lambda: add(num1), width=5)
button1.grid(row=1, column=0)
num2 = '2'
button1 = Button(app, text='2', command= lambda: add(num2), width=5)
button1.grid(row=1, column=1)
num3 = '3'
button1 = Button(app, text='3', command= lambda: add(num3), width=5)
button1.grid(row=1, column=2)
num4 = '4'
button1 = Button(app, text='4', command= lambda: add(num4), width=5)
button1.grid(row=2, column=0)
num5 = '5'
button1 = Button(app, text='5', command= lambda: add(num5), width=5)
button1.grid(row=2, column=1)
num6 = '6'
button1 = Button(app, text='6', command= lambda: add(num6), width=5)
button1.grid(row=2, column=2)
num7 = '7'
button1 = Button(app, text='7', command= lambda: add(num7), width=5)
button1.grid(row=3, column=0)
num8 = '8'
button1 = Button(app, text='8', command= lambda: add(num8), width=5)
button1.grid(row=3, column=1)
num9 = '9'
button1 = Button(app, text='9', command= lambda: add(num9), width=5)
button1.grid(row=3, column=2)
num0 = '0'
button1 = Button(app, text='0', command= lambda: add(num0), width=5)
button1.grid(row=4, column=1)
main.mainloop()
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python Programing for the Absoulte Beginner
On Sun, Aug 3, 2014 at 8:41 AM, Seymore4Head
wrote:
>>If the book is for Python 2 and you have 3.3 it should be print("Game Over")
>
> Thanks
>
> I am sure they had a good reason to add using 2 more characters for
> doing the same job.
One more, since you'll normally have a space after the word "print" anyway. :)
Language keywords are inflexible. Sure, it's nice and simple to do
straightforward output, but when you want to send that to stderr
instead of stdout, or change the separator between args, or change
what's at the end of what's printed (a newline, normally), or anything
like that, there needs to be special magical syntax added. Plus, it's
nearly impossible to do a simple replacement of print with something
else; pretty much the only way is to play with the code as it's being
compiled. With a function, all that is fixed; there are standard ways
of providing extra information (keyword arguments), you can replace
print with any other function just by shadowing it, and all this can
be done with perfectly normal syntax. This is how to tee print to a
file as well as stdout:
log_file = open("print.log","w")
orig_print = print
def print(*args, **kw):
if "file" not in kw: orig_print(*args, **kw, file=log_file)
orig_print(*args, **kw)
So easy! You can grab a reference to the original print functionality
with ordinary assignment (functions can be passed around and
referenced by names; statements can't), you can replace it just by
creating something else of the same name, and all its magic just comes
through as arguments.
There has been a move, now and then, to allow parens-free function
calls. If some such scheme were accepted, you could then use the
Python 2 syntax, and it would call the function; additionally, you
could use the shorthand for any other function, too - "sys.exit 1" for
instance. So far, there hasn't been a proposal that's satisfied all
the requirements and given a compelling argument for acceptance, but I
don't think the Python devs are philosophically opposed to the
concept.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: 3 Suggestions to Make Python Easier For Children
On 8/2/2014 3:46 AM, Mark Lawrence wrote: On 02/08/2014 07:45, Mark Summerfield wrote: Last week I spent a couple of days teaching two children (10 and 13 -- too big an age gap!) how to do some turtle graphics with Python. Neither had programmed Python before -- one is a Minecraft ace and the other had done Scratch. Suggestion #1: Make IDLE start in the user's home directory. Entirely agree. Please raise an enhancement request on the bug tracker if there isn't already one. Suggestion #2: Make all the turtle examples begin "from turtle import *" so no leading turtle. is needed in the examples. I'm not so sure about this, but raise an enhancement request and see what happens. Worst case it gets rejected, best case it gets accepted, implemented and patch applied. Suggestion #3: Make object(key=value, ...) legal and equiv of types.SimpleNamespace(key=value, ...). Haven't the faintest idea and too lazy to find out :) I suggest follow advice from #2. Mark L: I think that redirecting discussion to the tracker a hour after these ideas were posted, certainly for #2 and #3, which you were rightfully unsure about, was a bit premature. Enhancement ideas generally benefit from being cooked a bit longer on one or another discussion list. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
From git to hg
For gits looking to transition to hg (namely to work on cpython): http://demianbrecht.github.io/vcs/2014/07/31/from-git-to-hg/. My learnings beginning to work with mercurial while working on the stdlib. (This was sent out to core-mentorship already, just figured this is likely a larger audience with potentially more interested people making the same transition) -- Demian Brecht http://demianbrecht.github.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Correct type for a simple "bag of attributes" namespace object (was: 3 Suggestions to Make Python Easier For Children)
On Sat, Aug 2, 2014 at 2:05 PM, Chris Angelico wrote: > On Sun, Aug 3, 2014 at 6:46 AM, Mark Summerfield wrote: >> Naturally, I understand that adding a new name is a big deal and may be too >> much to ask for beginners. > > This is where you might want to consider putting some imports into > site.py. That way, you can set up your own customized Python, without > waiting for changes to be approved for core (which they probably won't > - new builtins have a high requirement for necessity, not just "I > don't want to have to type import"). Teaching a beginner a new programming language, but pretending it's Python, doesn't sound like a fantastic idea. -- Devin -- https://mail.python.org/mailman/listinfo/python-list
Re: 3 Suggestions to Make Python Easier For Children
On 8/2/2014 4:03 AM, Mark Summerfield wrote: On Saturday, 2 August 2014 08:46:04 UTC+1, Mark Lawrence wrote: On 02/08/2014 07:45, Mark Summerfield wrote: Summarizing my responses on the tracker... Suggestion #1: Make IDLE start in the user's home directory. Entirely agree. Please raise an enhancement request on the bug tracker if there isn't already one. Done: http://bugs.python.org/issue22121 As modified to fit existing behavior, this is a good idea and something will probably happen eventually. Suggestion #2: Make all the turtle examples begin "from turtle import *" so no leading turtle. is needed in the examples. I'm not so sure about this, but raise an enhancement request and see what happens. Worst case it gets rejected, best case it gets accepted, implemented and patch applied. Done: http://bugs.python.org/issue22122 I suggest that the existing doc should be clarified instead. Suggestion #3: Make object(key=value, ...) legal and equiv of types.SimpleNamespace(key=value, ...). Haven't the faintest idea and too lazy to find out :) I suggest follow advice from #2. Done: http://bugs.python.org/issue22123 This idea would mask bugs and is not necessary for the goal of making types.SimpleNamespace more accessible. It should have had more discussion here or on python-ideas. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Correct type for a simple "bag of attributes" namespace object (was: 3 Suggestions to Make Python Easier For Children)
On Sun, Aug 3, 2014 at 9:18 AM, Devin Jeanpierre wrote: > On Sat, Aug 2, 2014 at 2:05 PM, Chris Angelico wrote: >> On Sun, Aug 3, 2014 at 6:46 AM, Mark Summerfield wrote: >>> Naturally, I understand that adding a new name is a big deal and may be too >>> much to ask for beginners. >> >> This is where you might want to consider putting some imports into >> site.py. That way, you can set up your own customized Python, without >> waiting for changes to be approved for core (which they probably won't >> - new builtins have a high requirement for necessity, not just "I >> don't want to have to type import"). > > Teaching a beginner a new programming language, but pretending it's > Python, doesn't sound like a fantastic idea. It would still be Python, you just teach that certain lines just always go at the top of your scripts (like "from __future__ import print_function" if you're on Py2). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: From git to hg
On Sun, Aug 3, 2014 at 9:04 AM, Demian Brecht wrote: > For gits looking to transition to hg (namely to work on cpython): > http://demianbrecht.github.io/vcs/2014/07/31/from-git-to-hg/. > > My learnings beginning to work with mercurial while working on the stdlib. > > (This was sent out to core-mentorship already, just figured this is > likely a larger audience with potentially more interested people > making the same transition) The same transition, or the same the other direction, has been done plenty of times. Here's a reference that I keep handy (I'm fluent in git and a bit less so in hg - I don't do advanced hg work often): https://github.com/sympy/sympy/wiki/Git-hg-rosetta-stone ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
MRAB wrote: RISC OS didn't have a menu bar at the top of each window either; its menus were all pop-up. You didn't have to keep flicking the mouse at all! The main reason for having a menu bar is discoverability. The idea is that you can browse through the menus and get a feel for what commands are potentially available to you. That's not so easy to do when everything is hidden in contextual menus. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
Chris Angelico wrote: It's a little awkward when you have an invoicing screen and you put something like "P&O Shipping" as your customer name, and suddenly Alt-O takes you someplace different. An app that did that would be seriously broken, wouldn't it? The & should only be interpreted that way in menu items, etc., not in user data. but if the menu comes up right near where your eyes are already focused, you need to move _them_ less distance But putting the menu bar at the top of the window doesn't guarantee that it will be near where your eyes are. If you have a window taking up most of the screen and you're editing something near the bottom, a menu bar at the top of the window is nearly as far away as one at the top of the screen. It would make more sense to pop the menu up near the text cursor. There's no law that says a menu summoned by keystroke has to appear in the same place as one summoned by mouse. In any case, when you use a shortcut sequence, do you really *look* at the menu that comes up, or do you just memorise the appropriate alt-sequence? If you use it frequently, I suspect the latter. If you don't use it very often, having to look away doesn't matter so much. Okay. So you need to first click on something in the dock - that's the thing down the bottom of the screen, right? - and then go all the way up to the top of the screen to use its menu bar. Because of the "throw the mouse" effect, going *all* the way to the top takes a tiny fraction of a second and is almost effortless. Going any lesser distance takes *much* longer. I think I'd much rather have a popup menu - right-click the program's dock icon and get the menu right there where the mouse already is. Dock icons do have a contextual menu, but it's just a menu of windows. Fitting all of the app's menus in there would require hierarchical menus, which are an abomination you don't want to get me started on. :-) Oh wait, that requires people to understand more than a single mouse button, so it's contrary to Mac philosophy :) The Mac philosophy on that seems to be widely misunderstood. Having only one button on my mouse doesn't mean there's only one thing I can do with it. I can shift-click, option- click, command-click, and nowadays control-click, plus any combination of those. That's enough for anyone to keep in their head, I would have thought. There's also one concrete advantage to using modifiers instead of extra mouse buttons: you can provide feedback by changing the cursor when a modifier is held down. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
Roy Smith wrote: These days, I'm running multiple 24 inch monitors. The single menu bar paradigm starts to break down in an environment like that. Yes, that's an issue. However, even on a large screen, most of my windows are at least half a screen high, putting their tops a considerable distance from where I'm working. And the targeting effect means that a target at the top of the screen is still easier to hit than one half way up. Multiple screens are a problem. Probably what should happen is for the menu bar to move to the screen holding the currently active window, instead of being tied to one "primary" screen. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Correct type for a simple "bag of attributes" namespace object (was: 3 Suggestions to Make Python Easier For Children)
On Sat, Aug 2, 2014 at 2:46 PM, Mark Summerfield wrote: > On Saturday, 2 August 2014 20:58:59 UTC+1, Ben Finney wrote: >> Steven D'Aprano writes: >> >> > If you need instances which carry state, then object is the wrong >> > class. > > Fair enough. > >> Right. The 'types' module provides a SimpleNamespace class for the >> common "bag of attributes" use case:: >> >> >>> import types >> >>> foo = types.SimpleNamespace() >> >>> foo.x = 3 >> >>> foo >> namespace(x=3) > > This is too much for children (& beginners). > > But perhaps what I should be asking for is for a new built-in that does what > types.SimpleNamespace() does, so that without any import you can write, say, > > foo = namespace(a=1, b=2) > # or > bar = namespace() > bar.a = 1 > > where under the hood namespace has the same behavior as > types.SimpleNamespace(). > > Naturally, I understand that adding a new name is a big deal and may be too > much to ask for beginners. from types import SimpleNamespace as namespace Just have them put that at the top of each file, and tell them not to worry about what it does. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On Sun, Aug 3, 2014 at 10:01 AM, Gregory Ewing wrote: > Chris Angelico wrote: >> >> It's a little awkward when you have >> an invoicing screen and you put something like "P&O Shipping" as your >> customer name, and suddenly Alt-O takes you someplace different. > > > An app that did that would be seriously broken, wouldn't it? > The & should only be interpreted that way in menu items, etc., > not in user data. Mnemonics can also be used on text labels, and then they apply to the adjacent field - for instance, you could have "_Name" followed by an entry field for the Name, and hitting Alt-N will take you to that field. The app I'm talking about used a label to show the customer's name, and we had exactly that issue (although more often with couples' names - for instance, if we had an order from John and Mary Smith, but didn't know their full names, we'd identify them as J&M Smith, and voila, Alt-M would take us to... whatever field came after the display of the name (which was the address). To be quite honest, that particular program was a lot more broken than that. But still, it did drive home the value of using ~ instead of & for that job. And of course, _ makes enough sense that we can accept its potential for collisions. (Plus it's usually possible to disable underscore interpretation. Or, more properly, you have to explicitly enable their interpretation; in GTK, I have to call set_use_underline(1) before it'll create a mnemonic.) >> but if the menu comes up >> right near where your eyes are already focused, you need to move >> _them_ less distance > > > But putting the menu bar at the top of the window doesn't > guarantee that it will be near where your eyes are. If > you have a window taking up most of the screen and you're > editing something near the bottom, a menu bar at the top > of the window is nearly as far away as one at the top of > the screen. Putting it at the top of the window cannot possibly make it further away than putting it at the top of the screen. It's potentially going to be a lot closer, but at its worst, it'll be just as bad (modulo the title bar's height). > It would make more sense to pop the menu up near the text > cursor. There's no law that says a menu summoned by > keystroke has to appear in the same place as one summoned > by mouse. Sure. And I know of plenty of applications where that's possible. The standard used to be Shift-F10 to bring up a context menu, identical to right-clicking the mouse except that the menu appears at the object you're working on rather than at the mouse's location. These days, you often get something like that on the Menu key (aka the other Windows key, on some keyboards); same result. But that's a context menu, not the pull-down menu; although it's common to have the same menu items on them. > In any case, when you use a shortcut sequence, do you > really *look* at the menu that comes up, or do you just > memorise the appropriate alt-sequence? If you use it > frequently, I suspect the latter. If you don't use it > very often, having to look away doesn't matter so much. If I'm using "Alt-F, O" as a command keystroke, then sure, it doesn't make any difference where the menu is. But often I'll pull down a menu, then look at it to figure out what I want to hit. Once my eye has found it, I'll press its underlined letter, so I still don't use the mouse; but I do need it to have a mnemonic, and I need the entire menu to be near my eye. >> Okay. So you need to first click on something in the dock - that's the >> thing down the bottom of the screen, right? - and then go all the way >> up to the top of the screen to use its menu bar. > > Because of the "throw the mouse" effect, going *all* the > way to the top takes a tiny fraction of a second and is > almost effortless. Going any lesser distance takes > *much* longer. Right, but it still takes time. Also, if your mouse is set fast enough to go all the way from the bottom to the top of the screen in less than 0.1s, then either your screen is fairly small (may have been true in the past, but is getting pretty rare now), or you seriously penalize any going-less-distance operations. In fact, it becomes self-perpetuating: if you set the mouse fast, it becomes really important to use the edges and avoid the middle, and if applications always use the edges and never the middle, it's really important to set your mouse faster. Conversely, slower mouse settings mean it's easier to be precise with interior movements, while reducing the advantage of the borders. But no matter how fast you set the mouse, it still takes a nonzero time to move it to a specific position. The absolute easiest place to reach is... where you already are. Put the menu there! That's what popup menus are for. >> I think I'd much >> rather have a popup menu - right-click the program's dock icon and get >> the menu right there where the mouse already is. > > Dock icons do have a contextual menu, but it's just a > menu of windows. Fi
Re: Tkinter grid autosize help
On 8/2/2014 6:53 PM, Nicholas Cannon wrote:
On Saturday, August 2, 2014 10:38:28 PM UTC+8, Nicholas Cannon wrote:
So i have a basic calculator program and i have a label that i want to go across
>> the top to show the numbers and stuff like on a normal calculator.
The buttons are labelled already with numbers. Whatever stuff you meant,
is not diplayed.
The only way i can make the buttons look neat and then when i keep
>> pressing one the label gets larger and then half the buttons
>> move out of the screen.
Since nothing gets bigger, I have no idea what you mean.
>> I cant seem to fix this i have tried columnspan, columnconfigure
and heaps of other stuff and non works it always expands.
>> is there a way i can stop the grid from expanding?
If I shrink the window horizontally, the minimun size is 3 columns.
If I shrink vertically, bottom buttons disappear. I am not sure why.
ok here is the code:
Only some of it.
from tkinter import *
def add(*args): print(args)
#window setup
main = Tk()
main.title('Calculator')
main.geometry('300x350')
main.resizable()
app = Frame(main)
app.grid()
app.columnconfigure(0, weight=500)
app.columnconfigure(1, weight=500)
You left out column 2.
#number view label
number = ' '
numberView = Label(app, text= number)
numberView.grid(row=0, column=0, columnspan=100)
What you need for a changing label is
number = StringVar()
number.set('')
numberView = Label(app, textvariable=number)
but see below
#Num Pad Buttons below
num1 = '1'
button1 = Button(app, text='1', command= lambda: add(num1), width=5)
button1.grid(row=1, column=0)
You are using the braindead telephone keypad layout.
Calculators and number keypads have the more sensible layout
7 8 9
4 5 6
1 2 3
0
num2 = '2'
button1 = Button(app, text='2', command= lambda: add(num2), width=5)
button1.grid(row=1, column=1)
num3 = '3'
button1 = Button(app, text='3', command= lambda: add(num3), width=5)
button1.grid(row=1, column=2)
num4 = '4'
button1 = Button(app, text='4', command= lambda: add(num4), width=5)
button1.grid(row=2, column=0)
num5 = '5'
button1 = Button(app, text='5', command= lambda: add(num5), width=5)
button1.grid(row=2, column=1)
num6 = '6'
button1 = Button(app, text='6', command= lambda: add(num6), width=5)
button1.grid(row=2, column=2)
num7 = '7'
button1 = Button(app, text='7', command= lambda: add(num7), width=5)
button1.grid(row=3, column=0)
num8 = '8'
button1 = Button(app, text='8', command= lambda: add(num8), width=5)
button1.grid(row=3, column=1)
num9 = '9'
button1 = Button(app, text='9', command= lambda: add(num9), width=5)
button1.grid(row=3, column=2)
num0 = '0'
button1 = Button(app, text='0', command= lambda: add(num0), width=5)
button1.grid(row=4, column=1)
)
This sort of repetitious code is crying for a loop. For one thing, if
you want to change the buttons, there should only be one Button call to
modify. Since I am still learning to write tkinter myself, I wrote the
following, which I suspect does what you wanted and a bit more.
from tkinter import *
main = Tk()
main.title('Calculator')
main.geometry('300x350')
#main.resizable() # does nothing
app = Frame(main)
app.grid()
total = IntVar()
total.set(0)
entry = StringVar()
entry.set('')
Label(app, text='Total').grid(row=0, column=0)
Label(app, textvariable=total).grid(row=0, column=1, columnspan=3)
Label(app, text='Entry').grid(row=1, column=0)
Label(app, textvariable=entry).grid(row=1, column=1, columnspan=3)
def append(digit):
entry.set(entry.get() + digit)
def add():
total.set(total.get() + int(entry.get()))
entry.set('')
def sub():
total.set(total.get() - int(entry.get()))
entry.set('')
header_rows = 2
for num, r, c in (
('7', 0, 0), ('8', 0, 1), ('9', 0, 2),
('4', 1, 0), ('5', 1, 1), ('6', 1, 2),
('1', 2, 0), ('2', 2, 1), ('3', 2, 2),
('0', 3, 0), ('+', 3, 1), ('-', 3, 2),):
cmd = {'+':add, '-':sub}.get(num, lambda num=num: append(num))
b = Button(app, text=num, command=cmd, width=5)
b.grid(row=header_rows+r, column=c)
main.mainloop()
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: Tkinter grid autosize help
On Saturday, August 2, 2014 5:53:12 PM UTC-5, Nicholas Cannon wrote:
> So i have a basic calculator program and i
> have a label that i want to go across the top to show the
> numbers and stuff like on a normal calculator. The only
> way i can make the buttons look neat and then when i keep
> pressing one the label gets larger and then half the
> buttons move out of the screen.
A Tkinter Label widget will "naturally" adjust its size to
accommodate the text it contains.
> I cant seem to fix this i have tried columnspan,
> columnconfigure and heaps of other stuff and non works it
> always expands. is there a way i can stop the grid from
> expanding?
The "grid is expanding" because the first row of the grid
(which contains a label that is being updated by user input)
is expanding, and as such, all subsequent rows will expand
to match the first row.
You should use an Entry instead of a Label because:
1. Entry will accommodate values that exceed their current
size *WITHOUT* growing.
2. Label widgets do not allow direct input from the user.
Sure, in some cases you want to prevent the user from
editing text via the keyboard but *NOT* in this case! All
calculator apps should allow the use a choice between
mouse clicks or keyboard entry.
*HOWEVER*, if you do decide to implement the "numberView" as
an Entry widget, you will need to create a keypress filter
to prevent illegal input!
> ok here is the code:
> #window setup
> main = Tk()
> main.title('Calculator')
> main.geometry('300x350')
> main.resizable()
> app = Frame(main)
> app.grid()
> app.columnconfigure(0, weight=500)
> app.columnconfigure(1, weight=500)
> #number view label
> number = ' '
> numberView = Label(app, text= number)
> numberView.grid(row=0, column=0, columnspan=100)
> #Num Pad Buttons below
> num1 = '1'
> button1 = Button(app, text='1', command= lambda: add(num1), width=5)
> button1.grid(row=1, column=0)
> num2 = '2'
> button1 = Button(app, text='2', command= lambda: add(num2), width=5)
> button1.grid(row=1, column=1)
> num3 = '3'
> button1 = Button(app, text='3', command= lambda: add(num3), width=5)
> button1.grid(row=1, column=2)
> num4 = '4'
> button1 = Button(app, text='4', command= lambda: add(num4), width=5)
> button1.grid(row=2, column=0)
> num5 = '5'
> button1 = Button(app, text='5', command= lambda: add(num5), width=5)
> button1.grid(row=2, column=1)
> num6 = '6'
> button1 = Button(app, text='6', command= lambda: add(num6), width=5)
> button1.grid(row=2, column=2)
> num7 = '7'
> button1 = Button(app, text='7', command= lambda: add(num7), width=5)
> button1.grid(row=3, column=0)
> num8 = '8'
> button1 = Button(app, text='8', command= lambda: add(num8), width=5)
> button1.grid(row=3, column=1)
> num9 = '9'
> button1 = Button(app, text='9', command= lambda: add(num9), width=5)
> button1.grid(row=3, column=2)
> num0 = '0'
> button1 = Button(app, text='0', command= lambda: add(num0), width=5)
> button1.grid(row=4, column=1)
> main.mainloop()
A few points about your code:
1. "add" is a horrendous name for a function that updates
the numerical display, ESPECIALLY in an application that
is used to add, subtract, blah-blah-blah!
2. You should use a loop to layout the "grid of buttons",
which could be accomplished in just a mere couple lines of
code.
3. Declaring the value of the lambda arguments seems
superfluous to me.
Finally, there is always more to an interface than we
initially imagine. For instance, the width of the
"numberView" should fill the containing window to allow the
user "view flexibility", however, if the entry is allowed to
be dynamic and the "number grid" is not dynamic, then the
application is not going to feel very professional. Of
course, at this time, just getting something working is most
important. We can jazz it up later :)
Here is a slightly modified version of your code that may
help you get going in the correct direction. Note, i am
*NOT* going to write this code for you, i will offer *slight*
suggestions and comments where i believe improvements could
be made, but you are required to do the heavy lifting.
# START CODE
import Tkinter as tk
from Tkconstants import E, W, END
def update_entry(arg):
oldValue = entry.get()
entry.delete(0, END)
entry.insert(0, oldValue + arg)
def onKeyPress_entry(event):
key = event.keysym.lower()
print 'The user pressed {0}'.format(key)
#
# The following conditional showcases how to prevent
# illegal input but utilizing a return value of "break"
if key == 'w':
print 'The char "w" is not allowed!'
return "break"
app = tk.Tk()
app.title('Calculator')
app.geometry('300x350')
entry = tk.Entry(app)
entry.grid(row=0, column=0, sticky=E+W, columnspan=3)
entry.bind("", onKeyPress_entry)
if True:
# OPTION_1: Create buttons with repetitive code:
w = tk
Re: Tkinter grid autosize help
On Saturday, August 2, 2014 10:38:28 PM UTC+8, Nicholas Cannon wrote: > So i have a basic calculator program and i have a label that i want to go > across the top to show the numbers and stuff like on a normal calculator. The > only way i can make the buttons look neat and then when i keep pressing one > the label gets larger and then half the buttons move out of the screen. I > cant seem to fix this i have tried columnspan, columnconfigure and heaps of > other stuff and non works it always expands. is there a way i can stop the > grid from expanding? Ok so I have just started out Tkinter and I feel I should study more of it because some of the code given is quite intimidating to me right now. Also I have only been coding python for 3 months right now. I think I need to learn how to write python better haha. I appreciate the help guys. -- https://mail.python.org/mailman/listinfo/python-list
Re: Correct type for a simple "bag of attributes" namespace object
On 8/2/2014 5:16 PM, Mark Lawrence wrote: On 02/08/2014 22:05, Chris Angelico wrote: On Sun, Aug 3, 2014 at 6:46 AM, Mark Summerfield wrote: But perhaps what I should be asking for is for a new built-in that does what types.SimpleNamespace() does, so that without any import you can write, say, foo = namespace(a=1, b=2) # or bar = namespace() bar.a = 1 where under the hood namespace has the same behavior as types.SimpleNamespace(). Naturally, I understand that adding a new name is a big deal and may be too much to ask for beginners. This is where you might want to consider putting some imports into site.py. That way, you can set up your own customized Python, without waiting for changes to be approved for core (which they probably won't - new builtins have a high requirement for necessity, not just "I don't want to have to type import"). ChrisA I'd forgotten all about site.py so went to the 3.4.1 docs and found "Deprecated since version 3.4: Support for the “site-python” directory will be removed in 3.5.". site-python is *nix only and differetn from site.py, which will not go away. I believe PYTHONSTARTUP is also cross platform. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Correct type for a simple "bag of attributes" namespace object
On 8/2/2014 8:59 PM, Ian Kelly wrote: On Sat, Aug 2, 2014 at 2:46 PM, Mark Summerfield wrote: On Saturday, 2 August 2014 20:58:59 UTC+1, Ben Finney wrote: Steven D'Aprano writes: If you need instances which carry state, then object is the wrong class. Fair enough. Right. The 'types' module provides a SimpleNamespace class for the common "bag of attributes" use case:: >>> import types >>> foo = types.SimpleNamespace() >>> foo.x = 3 >>> foo namespace(x=3) This is too much for children (& beginners). But perhaps what I should be asking for is for a new built-in that does what types.SimpleNamespace() does, so that without any import you can write, say, foo = namespace(a=1, b=2) # or bar = namespace() bar.a = 1 where under the hood namespace has the same behavior as types.SimpleNamespace(). Naturally, I understand that adding a new name is a big deal and may be too much to ask for beginners. from types import SimpleNamespace as namespace Just have them put that at the top of each file, and tell them not to worry about what it does. In fact, for the original usecase, put it in a 'template file' that also includes a turtle import. For one of my projects, I have @template with several lines of boilerplate that I use for new files. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Tkinter grid autosize help
On 8/2/2014 10:16 PM, Terry Reedy wrote:
On 8/2/2014 6:53 PM, Nicholas Cannon wrote:
The only way i can make the buttons look neat and then when i keep
pressing one the label gets larger and then half the buttons
move out of the screen
With my code below, I tried entering a 20 digit number and the button
boxes separate horizontally. This is not exactly what you describe, but
it does mess up the initially neat display.
is there a way i can stop the grid from expanding?
One thing I might do, besides using an entry box, it to grid the buttons
in a separate frame. I wrote the code below, with the header_rows
variable, with that in mind.
This sort of repetitious code is crying for a loop. For one thing, if
you want to change the buttons, there should only be one Button call to
modify. Since I am still learning to write tkinter myself, I wrote the
following, which I suspect does what you wanted and a bit more.
from tkinter import *
main = Tk()
main.title('Calculator')
main.geometry('300x350')
#main.resizable() # does nothing
app = Frame(main)
app.grid()
total = IntVar()
total.set(0)
entry = StringVar()
entry.set('')
Label(app, text='Total').grid(row=0, column=0)
Label(app, textvariable=total).grid(row=0, column=1, columnspan=3)
Label(app, text='Entry').grid(row=1, column=0)
Label(app, textvariable=entry).grid(row=1, column=1, columnspan=3)
def append(digit):
entry.set(entry.get() + digit)
def add():
total.set(total.get() + int(entry.get()))
entry.set('')
def sub():
total.set(total.get() - int(entry.get()))
entry.set('')
header_rows = 2
for num, r, c in (
('7', 0, 0), ('8', 0, 1), ('9', 0, 2),
('4', 1, 0), ('5', 1, 1), ('6', 1, 2),
('1', 2, 0), ('2', 2, 1), ('3', 2, 2),
('0', 3, 0), ('+', 3, 1), ('-', 3, 2),):
cmd = {'+':add, '-':sub}.get(num, lambda num=num: append(num))
b = Button(app, text=num, command=cmd, width=5)
b.grid(row=header_rows+r, column=c)
main.mainloop()
With regard to your next message: If you do not understand the function
definitions above, including the lambda expression, and the loop, you
should definitely look more at the tutorial.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python Programing for the Absoulte Beginner
On Sun, 3 Aug 2014 08:30:15 +1000, Chris Angelico wrote:
>On Sun, Aug 3, 2014 at 8:13 AM, Seymore4Head
> wrote:
>> https://www.google.com/webhp?hl=en&tab=ww&gws_rd=ssl#hl=en&q=python+programing+for+the+absolute+beginner
>>
>> There is a book listed as a PDF.
>>
>> When I try the first example of print "Game Over" I get a syntax
>> error.
>>
>> I have tried running the command line and the GUI. I get the feeling
>> there is something else I need to run.
>>
>> http://imgur.com/RH3yczP
>
>Try this instead:
>
>print("Game Over")
>
>You're looking at a Python 2 book, and you're running Python 3. I
>would recommend instead getting a Python 3 tutorial:
Or do as I did, and install Python 2.
--
Steve Hayes from Tshwane, South Africa
Web: http://www.khanya.org.za/stevesig.htm
Blog: http://khanya.wordpress.com
E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python Programing for the Absoulte Beginner
On Sun, Aug 3, 2014 at 3:11 PM, Steve Hayes wrote: >>You're looking at a Python 2 book, and you're running Python 3. I >>would recommend instead getting a Python 3 tutorial: > > Or do as I did, and install Python 2. Better to install and learn Python 3. Much better. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Programing for the Absoulte Beginner
On Sun, 3 Aug 2014 15:12:02 +1000, Chris Angelico wrote: >On Sun, Aug 3, 2014 at 3:11 PM, Steve Hayes wrote: >>>You're looking at a Python 2 book, and you're running Python 3. I >>>would recommend instead getting a Python 3 tutorial: >> >> Or do as I did, and install Python 2. > >Better to install and learn Python 3. Much better. I've got too big an investment in books on Python 2, and there are no books available on Python 3 (I don't regard downloadable PDFs or other onlines stuff as "books"). -- Steve Hayes from Tshwane, South Africa Web: http://www.khanya.org.za/stevesig.htm Blog: http://khanya.wordpress.com E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Programing for the Absoulte Beginner
On 08/02/2014 10:20 PM, Steve Hayes wrote: there are no books available on Python 3 (I don't regard downloadable PDFs > or other onlines stuff as "books"). That's a very broad... and very *wrong* statement. -- Shiny! Let's be bad guys. Reach me @ memilanuk (at) gmail dot com -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Programing for the Absoulte Beginner
On Sun, Aug 3, 2014 at 3:20 PM, Steve Hayes wrote: > On Sun, 3 Aug 2014 15:12:02 +1000, Chris Angelico wrote: > >>On Sun, Aug 3, 2014 at 3:11 PM, Steve Hayes wrote: You're looking at a Python 2 book, and you're running Python 3. I would recommend instead getting a Python 3 tutorial: >>> >>> Or do as I did, and install Python 2. >> >>Better to install and learn Python 3. Much better. > > I've got too big an investment in books on Python 2, and there are no books > available on Python 3 (I don't regard downloadable PDFs or other onlines stuff > as "books"). But there are plenty of courses for Python 3, and lots of people are happy to take online information when learning coding. (Personally, I can't be bothered with paper books at all. I get all my books online if I possibly can... or even get both, pay for the paper one to support the author, and then download it so I have something I can actually read and search.) Don't tie yourself to the Python branch that's not getting development (bugfixes, some IDLE enhancements, but no new features) unless you have a good reason to. For someone who's just starting out with Python, learn Python 3. Don't bother going into all the debates; if you have need of Python 2, you'll find out when the time comes; and when it does, you'll be better placed for having learned Python 3. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
