stripping (from item in list)
While preparing to my gui to the app I made I thought it would be nice
to be able to parse a text file with results using the same tool. So:
I read a result file to a list, and every record gets appended with
"\n" ...
OK, so I look up how to remove it. And this doesn't work
while c >=0:
x=games[c][0]
if x=="#":
del games[c] #This removes the comments from the file parsed
else:
games[c].rstrip('\n') #This does nothing, expected to remove \n
c=c-1
# Now we have a list with only proper lines
While all records in the remaining list now are valid, all also still
have "\n" at the end. What did I miss here?
Regards,
Martin S
--
https://mail.python.org/mailman/listinfo/python-list
Re: stripping (from item in list)
On Sun, Jul 20, 2014 at 7:40 PM, Martin S wrote:
> games[c].rstrip('\n') #This does nothing, expected to remove \n
>
> While all records in the remaining list now are valid, all also still
> have "\n" at the end. What did I miss here?
Strings don't change. When you call rstrip(), it returns a new string
which is the stripped value. You'll need to slot that back in:
games[c] = games[c].rstrip('\n')
However, there may be a better way to do this - possibly a cleaner parser.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: stripping (from item in list)
Craps should have guessed that was the problem. Must have
misunderstood the examples.
But thanks =)
And yes, definately should be able to build a better parser ... I want
it to work first.
/Martin S
2014-07-20 11:57 GMT+02:00 Chris Angelico :
> On Sun, Jul 20, 2014 at 7:40 PM, Martin S wrote:
>> games[c].rstrip('\n') #This does nothing, expected to remove \n
>>
>> While all records in the remaining list now are valid, all also still
>> have "\n" at the end. What did I miss here?
>
> Strings don't change. When you call rstrip(), it returns a new string
> which is the stripped value. You'll need to slot that back in:
>
> games[c] = games[c].rstrip('\n')
>
> However, there may be a better way to do this - possibly a cleaner parser.
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
--
Regards,
Martin S
--
https://mail.python.org/mailman/listinfo/python-list
Re: stripping (from item in list)
On Sun, Jul 20, 2014 at 8:06 PM, Martin S wrote: > And yes, definately should be able to build a better parser ... I want > it to work first. Fair enough. That's why I answered your actual question before mentioning that as a tacked-on almost postscript. :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Writing Python File at Specific Interval
On Thursday, July 10, 2014 5:21:01 AM UTC+5:30, Denis McMahon wrote: > On Wed, 09 Jul 2014 07:36:49 -0700, subhabangalore wrote: > > > > > The code (a basic crawler) would run every morning or evening, on a > > > predefined time. [This part is fine]. > > > > > > In the next part, I am trying to store the daily results to a new file. > > > > So what you want to do is store each day's results in a new file, so > > probably you want to create a filename that looks something like an iso > > 8601 date. > > > > Luckily for you python has this functionality available: > > > > https://docs.python.org/2/library/datetime.html#date-objects > > > > $ python > > Python 2.7.3 (default, Feb 27 2014, 19:58:35) > > [GCC 4.6.3] on linux2 > > Type "help", "copyright", "credits" or "license" for more information. > > >>> from datetime import date > > >>> fn = date.today().isoformat() + ".log" > > >>> print fn > > 2014-07-10.log > > >>> quit() > > $ > > > > Once you have a string containing your filename, you might use: > > > > fp = open( fn, "w" ) > > fp.write( data ) > > fp.close() > > > > -- > > Denis McMahon, denismfmcma...@gmail.com Dear Group, Thank you for your kind suggestion. It worked. Regards, Subhabrata Banerjee. -- https://mail.python.org/mailman/listinfo/python-list
Re: Improving Idle (was Re: Python 3 ...)
On 20/07/2014 02:42, Chris Angelico wrote: On Sun, Jul 20, 2014 at 11:31 AM, Rick Johnson wrote: Does the IDLE bug-tracker exist to *SOLVE* problems or to *PERPETUATE* them? Definitely the latter. If it weren't for that tracker, bugs would just quietly die on their own. The PSU has a roster for feeding the bugs, changing their litter, and all other bug-related duties, and when someone goes on holidays and forgets to schedule a replacement, heaps of bugs just inexplicably die. (The PSU generally conceals this faux pas under the name of a "release".) ChrisA An alternative is that the PSU wait until some raving lunatic, sado-masochistic nutter who actually likes triaging comes only and bumps some of the sillier, lonely bugs, e.g a three year old failing test case on a buildbot. Result, bug is closed as out of date. Click on the stats link at bugs.python.org and observe the result of this crazy type of behaviour. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Writing Python File at Specific Interval
On 20/07/2014 12:15, subhabangal...@gmail.com wrote: Dear Group, Thank you for your kind suggestion. It worked. Regards, Subhabrata Banerjee. I'm pleased to see that you have a solution. In return would you please use the mailing list https://mail.python.org/mailman/listinfo/python-list or read and action this https://wiki.python.org/moin/GoogleGroupsPython to prevent us seeing double line spacing and single line paragraphs, thanks. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Anything better than asyncio.as_completed() and asyncio.wait() to manage execution of large amount of tasks?
Hi Maxime, many thanks for your great solution. It would be so great to have it in stock asyncio and use it out-of-the-box... I've made 4 fixes to it that are rather of "cosmetic" nature. Here is the final version: import asyncio from concurrent import futures def as_completed_with_max_workers(tasks, *, loop=None, max_workers=5, timeout=None): loop = loop if loop is not None else asyncio.get_event_loop() workers = [] pending = set() done = asyncio.Queue(maxsize=max_workers, loop=loop) # Valery: respect the "loop" parameter exhausted = False timeout_handle = None # Valery: added to see, if we indeed have to call timeout_handle.cancel() @asyncio.coroutine def _worker(): nonlocal exhausted while not exhausted: try: t = next(tasks) pending.add(t) yield from t yield from done.put(t) pending.remove(t) except StopIteration: exhausted = True def _on_timeout(): for f in workers: f.cancel() workers.clear() # Wake up _wait_for_one() done.put_nowait(None) @asyncio.coroutine def _wait_for_one(): f = yield from done.get() if f is None: raise futures.TimeoutError() return f.result() workers = [asyncio.async(_worker(), loop=loop) for _ in range(max_workers)] # Valery: respect the "loop" parameter if workers and timeout is not None: timeout_handle = loop.call_later(timeout, _on_timeout) while not exhausted or pending or not done.empty(): yield _wait_for_one() if timeout_handle: # Valery: call timeout_handle.cancel() only if it is needed timeout_handle.cancel() best regards -- Valery A.Khamenya -- https://mail.python.org/mailman/listinfo/python-list
Re: stripping (from item in list)
On 7/20/2014 5:40 AM, Martin S wrote:
while c >=0:
x=games[c][0]
if x=="#":
del games[c] #This removes the comments from the file parsed
else:
games[c].rstrip('\n') #This does nothing, expected to remove \n
Chris already pointed out error here.
c=c-1
# Now we have a list with only proper lines
I believe what you are aiming for is
games = [line.rstrip('\n') for line in games if line[0] != '#']
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"!
BUG 1: FileDialog Duplicity: If you open the IDLE application (either utilizing the "shell window" or "editor window") and then go to the "File" menu and choose the "Open" command you will see a file dialog appear, okay, nothing wrong with that. HOWEVER, if you go to the "File" menu *AGAIN* choose the "Open" command, you will see *ANOTHER* file dialog open. Note that on windows (at least), the new file dialogs are stacked *perfectly* on top of old filedialogs, so you will need to move the top dialog before you can see any hiding below. And not only can you open more than one dialog ,there seems to be no limit on the number of dialogs you can open! Modal dialogs *MUST* be limited to a "one dialog at a time" policy. And even *IF* the designers of Tkinter were too naieve to relize this, the designers of IDLE should have been intelligent enough to ensure this cannot happen, because, opening more than one filedialog is about has useful as buying shoes in sets of greater than two. Two feet -> two shoes. One document -> one dialog or rather, One dialog per "active" document! And since IDLE is not a "tabbed editor", only *1* document is going to be displayed at a time. The troubling issue is, Tkinter filedialogs are working fine (see my code at the end of this message which proves my statement!), whereas the IDLE dialogs which utilize Tkinter code are not! POSSIBLE FIX FOR "BUG 1": If for some reason IDLE is not using the tkFileDialogs, a simple "request contract" can solve the issue by setting a "counter variable" like "activeFileDialogs = 0", then incrementing the counter by 1 each time a filedialog is displayed, and then decrementing the value by one each time a filedialog is closed. Furturemore, each time a filedialog is "requested", the logic will deny the request *IF* the value of "activeFileDialogs" is greater than one. However, this all seems rediculous since Tkinter filedialogs are working as expected! (see code at end of this message) BUG 2: FileDialog "Hide and go seek": When you have a filedialog displayed *AND* the "parent window" from which you spawned the filedialog is in "full screen" mode, if you (or your OS) decides to "unfocus" the "parent window" window, when you return you will *NOT* see the open dialog, because the filedialog will be hidden *BEHIND* the full screen "parent window". Again, this only happens in IDLE, but in my example code at the end of this message you will find that the dialog behaves as expected. BUG 3: FileDialog not using "native" dialogs anymore. Currently, when opening a filedialog in IDLE, i don't get the "shortcut pane" that is visible in my Windows Explorer application, *HOWEVER*, before i updated to version 2.7.8 i swear it was there! WHAT THE HECK HAPPNED? REFERENCES: # BEGIN CODE # The following code proves that Tkinter filedialogs are # behaving in expected manners (properly placed as children # of the windows which "own" them, and following normal # focus patterns of "child windows" -- therfore, the problem # *MUST* be an IDLE problem. # # Tested on Python 2.7.8 # import Tkinter as tk from tkFileDialog import askopenfilename, asksaveasfilename class App(tk.Tk): def __init__(self): tk.Tk.__init__(self) self._createMenus() def _createMenus(self): menubar = tk.Menu(self) self.config(menu=menubar) filemenu = tk.Menu(menubar) menubar.add_cascade(label='File', menu=filemenu) filemenu.add_command(label='Open', command=self.requestOpenDialog) filemenu.add_command(label='Save As', command=self.requestSaveAsDialog) def _requestFileDialog(self, func, **kw): path = func(**kw) return path def requestOpenDialog(self, **kw): return self._requestFileDialog(askopenfilename, **kw) def requestSaveAsDialog(self, **kw): return self._requestFileDialog(asksaveasfilename, **kw) if __name__ == '__main__': app = App() app.mainloop() # # END CODE -- https://mail.python.org/mailman/listinfo/python-list
Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"!
On 20/07/2014 22:14, Rick Johnson wrote: [loads of stuff snipped] Why bother writing all that here, why not put it all on the bug tracker, or has that already been done, either by you or someone else? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"!
On 20-7-2014 23:14, Rick Johnson wrote: > And since IDLE is not a "tabbed editor", only *1* document > is going to be displayed at a time. False. Idle opens any number of documents at the same time just fine (in different windows - rather than tabs). While I don't see the use case for the possibility of having multiple file dialogs open at the same time, it doesn't really hurt either does it? > > BUG 3: FileDialog not using "native" dialogs anymore. > > > Currently, when opening a filedialog in IDLE, i don't get > the "shortcut pane" that is visible in my Windows Explorer > application, *HOWEVER*, before i updated to version 2.7.8 i > swear it was there! Not sure what you mean. What's the "shortcut pane"? I do notice that my Idle from Python 3.4.1 does indeed not use a native file dialog, it has a weird icon bar at the left side (win xp era layout?) My idle from 2.7.6 (haven't upgraded yet) uses the native explorer dialog. That is odd indeed. Maybe there's a reason for it, maybe it's a bug, I don't know. Irmen -- https://mail.python.org/mailman/listinfo/python-list
Idle's Shell: prompts and indents (was ...) Idle users please read
On 7/19/2014 9:31 PM, Rick Johnson wrote:
On Saturday, July 19, 2014 3:45:07 PM UTC-5, Terry Reedy wrote:
Idle's Shell currently uses a primary prompt ('>>> '), no secondary
prompt*, and tabs for indents. This is a compromise between conflicting
goals. It works but perhaps we can do better.
* The third paragraph below explains that Shell's prompt is a statement
prompt rather than line prompt, so that a secondary line prompt would
not be appropriate.
The problem with tabs is that tk displays them as a jump to the next
'tab stop'. For fixed pitch fonts, the virtual tab stops are set at 8
space intervals. For proportional fonts, I suspect the spacing is 8 em
quads, where an em quad is the height of the font, which is also about
the width of the widest character. An em quad is much larger than the
width of a space character, perhaps 4x larger and perhaps 1.5 times the
average width. Because of no secondary prompt, the first fixed-pitch
indent looks like an indent of 4 spaces after a 'secondary prompt' of '
', while subsequent indents are really 8 spaces. The indents appear
are uneven and the subsequent indents chew up screen width too quickly.
For proportional fonts, the problem is worst as the indents are about
12 characters.
http://bugs.python.org/issue7676
indention. I know this issue is going to be a bit more
trouble to solve than the previous two "event" issues
To understand *HOW* we might resolve this issue, *FIRST* we
must understand the origins of the issue
The problem originates in differences between the console - interactive
python interaction and Idle Shell - execution server interaction.
Interactive python prints prompts to and reads lines from the console.
Once the user submits a line by hitting return, it cannot be edited.
(This is true on Widows. Could any linux and mac user confirm for their
systems?)
The Idle Shell is much more active than at least the Windows console,
and it is statement rather than line oriented. This is the important
point. The Shell '>>> ' prompt is prompting for a complete statement,
not a single line. This difference of meaning should be documented if it
is not now.
Until a user indicates that a statement is completed, the user can edit
*any* part of the statement, not just the last line. While Shell
monitors keystrokes and modifies the text accordingly with color and
indents, it does not send the statement to the execution server, which
is running idle code in batch-mode python, until the statment is
complete. The execution server then exec()s the statement inside the
Executive.run_code method and sends and response back.
Being able to enter, edit, and recall complete statements is an valuable
Shell feature.
The problem manifests itself when the user wants to write
> commands that span *MORE* than one line.
Right. Multiline statement issues go away when a statement is a single
line. Now to the ideas on the tracker.
IDEA_1: Hey, lets just use 8 space indention for the
Or a tab for the first indent (this works if consistent)
*FIRST* level of indentation, and 4 space indention for
any *SUBSEQUENT* levels of indentation,
I am considering this as an option when the font is fixed pitch.
that would not solve the copy-paste problem *DIRECTLY*,
The advantage of a single tab is that it is easy to turn it into 4
spaces either in a custom copy or after pasting.
IDEA_2: Hey, lets just insert a "buffer prompt" for every
line that is *NOT* the *FIRST LINE* of the command, and
then use 4 spaces for indention... problem solved!
RESPONSE_2: Hardly! Can't do that because people cannot be
denied their "adolescent accessorizing" via font choice.
This idea, and your response, ignores the fact that Shell is *statement*
oriented. Inserting a secondary prompts inside statement text would mean
that they would have to first be protected from user editing and then
deleted by Idle before the statement is sent to the Executive.
IDEA_3: Hey, let's remove the embedded prompt from the
main shell window altogether and display it in a separate
"thin" area to the left -- sort of like how line numbers
are displayed in other IDEs. This would solve the copy paste
>issue *AND* the indention issue.
http://bugs.python.org/issue17535
GSOC Idle student Saimadhav Heblekar has worked on adding *optional*
line numbers to Idle editor windows. I plan to adapt the final patch to
the shell with, for instance '>>> ' and 'out:' labels.
As I said on the tracker, I think that output that is no longer dedented
with respect to input will then need some more to distinguish it. For my
copy of Idle, I have added blue and red background tint to standard and
error output and I think that works well.
we can take credit for Ricks idea from circa 2005,
Ideas don't count until recorded on the tracker.
RESPONSE_2: You fool! That would require *ACTUAL* skills
that we *DON'T* ha
Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"!
On Sunday, July 20, 2014 4:40:59 PM UTC-5, Irmen de Jong wrote: > On 20-7-2014 23:14, Rick Johnson wrote: > > And since IDLE is not a "tabbed editor", only *1* > > document is going to be displayed at a time. > False. Idle opens any number of documents at the same time > just fine (in different windows - rather than tabs). Yes, your statement is true, and here are a few facts about the IDLE interface that support your statement: 1. IDLE allows the "spawning" of an unlimited number of "IDLE editor windows", which each "editor window" acting as a (potential) container for a document -- which "loosely" emulates (albeit in a discombobulated manner) a "tabbed editor". 2. IDLE also allows one *OPTIONAL* instance of the "IDLE shell window" to exist. > While I don't see the use case for the possibility of > having multiple file dialogs open at the same time, it > doesn't really hurt either does it? Actually yes, it does, for the reasons i explained in my OP: Filedialogs should be "truly modal", and like any modal dialog, should present themselves to the user utilizing blocking -- that is the whole point of "modal dialogs", to *BLOCK* further execution of the application *UNTIL* the user provides (generally speaking) an "answer" to a "question". In order to facilitate *SMOOTH* interfacing between the user and the modal dialog, the "contract of modal dialogs" must be strictly obeyed: When presented with a modal dialog, a user is given only two choices -- he must *interact* with the dialog, or he must cancel the dialog. During the time which the dialog is displayed, all attempts by the user to unfocus, minimize, or otherwise exit the dialog will not be allowed -- except via the *explicitly* defined interaction mechanisms of the dialog itself, for instance, via "okay" and "cancel" buttons. So, even if IDLE does allow multiple "editor windows" to exists concurrently, allowing multiple filedialogs to exist concurrently is not only un-useful, it is downright confusing. GUI programming has been around for decades, so there is no excuse for us not creating smooth interactions between a user and his modal dialogs. > Not sure what you mean. What's the "shortcut pane"? I do > notice that my Idle from Python 3.4.1 does indeed not use > a native file dialog, it has a weird icon bar at the left > side (win xp era layout?) Yes, that is the legacy "shortcut bar" i'm referring to! Before upgrading, IDLE was utilizing the more updated version of windows explorer that includes quite a few personalized shortcuts. -- https://mail.python.org/mailman/listinfo/python-list
Re: Idle's Shell: prompts and indents (was ...) Idle users please read
On Mon, Jul 21, 2014 at 7:52 AM, Terry Reedy wrote:
> On 7/19/2014 9:31 PM, Rick Johnson wrote:
> The problem originates in differences between the console - interactive
> python interaction and Idle Shell - execution server interaction.
> Interactive python prints prompts to and reads lines from the console. Once
> the user submits a line by hitting return, it cannot be edited. (This is
> true on Widows. Could any linux and mac user confirm for their systems?)
If you mean that individual lines are separately edited, then yes,
that's the same on Linux.
> The Idle Shell is much more active than at least the Windows console, and it
> is statement rather than line oriented. This is the important point. The
> Shell '>>> ' prompt is prompting for a complete statement, not a single
> line. This difference of meaning should be documented if it is not now.
This is, in fact, Idle's greatest feature IMO. The ability to recall,
edit, and resubmit an entire function/class definition as a single
unit.
> The advantage of a single tab is that it is easy to turn it into 4 spaces
> either in a custom copy or after pasting.
If you're weighing up those two options specifically, I would tip the
balance toward a custom copy. If you paste into some other
application, it would be more consistent to work with four spaces for
every indentation level, rather than having every line begin with a
tab and then some spaces.
> This idea, and your response, ignores the fact that Shell is *statement*
> oriented. Inserting a secondary prompts inside statement text would mean
> that they would have to first be protected from user editing and then
> deleted by Idle before the statement is sent to the Executive.
The secondary prompts are actually quite annoying in copy/paste.
Anything that suppresses them is a distinct advantage IMO.
> As I said on the tracker, I think that output that is no longer dedented
> with respect to input will then need some more to distinguish it. For my
> copy of Idle, I have added blue and red background tint to standard and
> error output and I think that works well.
I'd have to have a look and see how that feels before I can judge
properly, but the notion of output not being indented by a prompt is
one that's found on... well, pretty much everything. Most command-line
interfaces work that way. Good MUD clients work hard to make sure that
the user's input is correctly indented by the prompt, even if the two
are quite separate in chronology; if you use input("") and
print(), you'll end up with the same kind of interface. Explaining the
difference in color will be different, so it'll have to work extra
well to make up for that. Also, you can copy and paste into an email,
which will lose color. Count me dubious but reserving judgment.
>>RESPONSE_2: You fool! That would require *ACTUAL* skills
>>that we *DON'T* have. Only rr knows how to "lock" the
>>scrolling events of two Tkinter widgets,
>
> Saimadhav has locked together a thin canvas with the text for line numbers.
> It works in all my texts. I am just waiting for him to try it with a thin
> text instead.
>
> If you know some secret you think he missed. please describe it here.
Huh, is combined scrolling really such an amazing thing? Only one
person in the whole world knows how to do it? So like this:
http://www.phdcomics.com/comics/archive.php?comicid=1723
http://catb.org/esr/writings/unix-koans/mcse.html
Considering that some GUI toolkits have that functionality as a core
feature (GTK scrolling is a bit more complex to support this exact
concept), I would be very much surprised if exactly one person knows
how to do it in Tk.
> Idea 4 (which I already suggested on the tracker). Put statement input
> prompts and output separators on lines by themselves. As with 3. above, use
> standard 4 space indents, as with
>
:
> def f(x):
> if x:
> print('got it')
> return 'something'
>
:
> f(3)
> ---
> got it
:
>
> Idle users other than Rick, any comments on the possible improvements?
I can't comment on how it interacts with the editor half of Idle, but
for the shell as a stand-alone app, and for copying and pasting into
other programs, this last idea is rather interesting. I'm broadly
happy with the current system (>>> def f(x):), and the prompt is a
little weird (">>>:"? but maybe "Python:" would be less weird; I don't
advise "Idle:" as it implies that something is idle that might be
busy), but this would make copy/paste that bit easier. It would tend
to de-emphasize the difference between input and output, though, which
may or may not be an issue. But definitely interesting.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Tabbed IDLE (was PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"!)
On 2014-07-20 23:40, Irmen de Jong wrote: > > And since IDLE is not a "tabbed editor", only *1* document > > is going to be displayed at a time. > > False. Idle opens any number of documents at the same time just > fine (in different windows - rather than tabs). This sounds like a failing of the OP's window-manager. Fluxbox lets me combine any number of windows into a tabbed interface, so IDLE *is* a tabbed editor on my machine (just like the Gimp). Moreover, it can even include other windows, so I just pulled together a tabbed IDLE interface that also has a terminal for interacting with git, a file-manager window for project management, and a mail window (because Zawinski's law[1]). ;-) -tkc [1] """ Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can. """ . -- https://mail.python.org/mailman/listinfo/python-list
Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"!
On Mon, Jul 21, 2014 at 8:44 AM, Rick Johnson wrote: > Filedialogs should be "truly modal", and like any modal > dialog, should present themselves to the user utilizing > blocking -- that is the whole point of "modal dialogs", to > *BLOCK* further execution of the application *UNTIL* the > user provides (generally speaking) an "answer" to a > "question". > > In order to facilitate *SMOOTH* interfacing between the user > and the modal dialog, the "contract of modal dialogs" must > be strictly obeyed: File dialogs can be modal or modeless. That's been true since the very first time I met them (which, admittedly, wasn't until the early 90s; maybe someone remembers earlier and can tell me if they were inherently modal 25+ years ago?), and there are good reasons for both operation styles. Even if your dialog is modal, it's extremely common to NOT block the application, but merely prevent interaction; otherwise, your main window won't repaint, which is generally considered to be a flaw. Rick, have you ever done any serious GUI programming in anything other than Tkinter? Are you seriously unaware of standard GUI widget functionality? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Tabbed IDLE (was PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"!)
On Mon, Jul 21, 2014 at 10:56 AM, Tim Chase wrote: > On 2014-07-20 23:40, Irmen de Jong wrote: >> > And since IDLE is not a "tabbed editor", only *1* document >> > is going to be displayed at a time. >> >> False. Idle opens any number of documents at the same time just >> fine (in different windows - rather than tabs). > > This sounds like a failing of the OP's window-manager. Fluxbox lets > me combine any number of windows into a tabbed interface, so IDLE > *is* a tabbed editor on my machine (just like the Gimp). I would draw a distinction there. With Fluxbox you may be able to build a tabbed interface out of a non-tabbed one, but that doesn't mean the program is tabbed. That's like saying that, with any of a large number of Linux desktop managers and window managers, I can have multiple virtual desktops, which means that I have infinite space on my display. No, I don't; I have an extra layer in there that provides that, but my display is still what it is. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Idle's Shell: prompts and indents (was ...) Idle users please read
On Sunday, July 20, 2014 4:52:36 PM UTC-5, Terry Reedy wrote: > On 7/19/2014 9:31 PM, Rick Johnson wrote: > > On Saturday, July 19, 2014 3:45:07 PM UTC-5, Terry Reedy wrote: > * The third paragraph below explains that Shell's prompt > is a statement prompt rather than line prompt, so that a > secondary line prompt would not be appropriate. Speaking strictly from the point of view of the *current* IDLE implementation, yes. > > To understand *HOW* we might resolve this issue, *FIRST* we > > must understand the origins of the issue > The problem originates in differences between the console > - interactive python interaction and Idle Shell - > execution server interaction Actually, the "problem" you are describing is fundamentally different from what i was talking about, but you *are* getting closer to the *real* source of the design flaws that prevent *easy* evolution of the IDLE software. The *real* problem is that the "interactive events" of the "editor window" and the "interactive events" of the "shell window" are far too tightly integrated with one another. I myself appreciate the finger saving principles of "DRY", however, sometimes, two distinct functionalities just cannot be implemented *IN A CLEAR MANNER* without repeating *some* of the code. We need to understand that IDLE is split into two distinct "modes", if you will -- the "interactive shell" and the "editor window". Attempting to use the same code to handle keystrokes for the shell *AND* the editor is a stumbling block to extending this mess. Instead, IDLE needs two distinct "pipelines" for which events for each *SIDE* of this "split personality" can be *written* and later, easily *COMPREHENDED* by the maintenance programmer. Our "real problem" is discombobulation, and until we wrangle the beast of discombobulation, we will never improve this software in a meaningful or clear manner. Instead, we will only render the software exponentially less readable. YOU CANNOT IMPROVE ANY SOFTWARE UNTIL YOU CAN GROK IT'S SOURCE > This idea, and your response, ignores the fact that Shell > is *statement* oriented. Inserting a secondary prompts > inside statement text would mean that they would have to > first be protected from user editing and then deleted by > Idle before the statement is sent to the Executive. Yes and no. ;-) Hiding the "secondary prompts" from the "execution server" is as simple as running the "command" through a "cleaner function" *BEFORE* it gets evaluated. As for the other issue of protecting the user from editing the "secondary prompts", all you need to do is add a few bits of extra logic to the backspace and clipboard events. But you *could* even just let the user be responsible for his own mistakes and allow documentation handle that issue. But either way, both can be achieved without a complete re- write *OR* fundamental architecture re-design. > Saimadhav Heblekar has worked on adding *optional* line > numbers to Idle editor windows. I plan to adapt the final > patch to the shell with, for instance '>>> ' and 'out:' > labels. As I said on the tracker, I think that output that > is no longer de-dented with respect to input will then need > some more to distinguish it. For my copy of Idle, I have > added blue and red background tint to standard and error > output and I think that works well. That sounds fine to me. There are many methods one can utilize to differentiate input from output. And i like your idea of input being black(with colorizer modification of course), valid output as *ALL* blue, and error output as *ALL* red. > Ideas don't count until recorded on the tracker. Hmm, okay. > Saimadhav has locked together a thin canvas with the text > for line numbers. It works in all my texts. I am just > waiting for him to try it with a thin text instead. If you > know some secret you think he missed. please describe it > here. How can i offer improvements if i don't know where to find the code? And besides, if my comments here "don't count" i will levy the punishment of Eric Theodore Cartman upon you: SCREW YOU GUYS, I'M GOING HOME! -- https://mail.python.org/mailman/listinfo/python-list
Re: Idle's Shell: prompts and indents (was ...) Idle users please read
On Mon, Jul 21, 2014 at 11:22 AM, Rick Johnson wrote: > How can i offer improvements if i don't know where to find > the code? Look in hg.python.org/cpython and see what you find. You never know, it might even be there! ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Improving Idle (was Re: Python 3 ...)
On 19/07/2014 21:45, Terry Reedy wrote: If you are talking about user processes, and we are talking about patching Idle, as opposed to Python or the OS (such as Windows), I disagree. If you are talking about the Idle process, then yes, I would prefer that once Idle starts, it run forever, and recover from any problems caused by users. Roger Serwy fixed many Idle shutdowns before being swallowed by a PhD program a year ago, but there is more to do. Which has just reminded me of this http://idlex.sourceforge.net/ which is available from pypi, with the last update dated 2014-06-02. I'll quote from the sourceforge page "IdleX is a collection of over twenty extensions and plugins that provide additional functionality to IDLE, a Python IDE provided in the standard library. It transforms IDLE into a more useful tool for academic research and development as well as exploratory programming. IdleX runs with Python 2.6, 2.7, and 3.x." -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"!
On Sunday, July 20, 2014 8:02:11 PM UTC-5, Chris Angelico wrote: > File dialogs can be modal or modeless. [...] and there are > good reasons for both operation styles [...] Are you > seriously unaware of standard GUI widget functionality? Chris i get so tired of your trolling, you cannot just post chastisements of me without proving your side beyond a shadow of a doubt, which you have failed (yet again) to do. Since most people in this community are not experienced with the bugs of IDLE, i will now present you with the steps required to reproduce the two filedialog bugs i mentioned in my first post of this thread. Chris, i challenge you to follow these direction and then report back on this thread your opinion on what "benefits" these buggy filedialog displays are offering to IDLE. Myself and others would just *love* to hear your opinions. STEPS TO REPRODUCE BUG 1: "Attack of the clones!" 1. Open the IDLE application 2. Maximize the window that appears 3. Go to the "File Menu" and choose the "Open" command Now repeat step 3 at least one more time, but feel free to keep opening new dialogs until your fingers bleed and/or eyes pop out. Okay, now tell us, in what manner can an "interface bug" like this be "beneficial"? STEPS TO REPRODUCE BUG 2: "Hide and go seek!" 1. Open the IDLE application 2. Maximize the window that appears 3. Go to the "File Menu" and choose the "Open" command 4. Without disturbing the dialog, minimize the main window 5. Using the taskbar icon, maximize the window Where is the dialog? How will you retrieve it *WITHOUT* reducing the size of the window? And even if you are smart enough to "intuit" what happened to the dialog, and how to retrieve it, how will a noobie "intuit" such a disappearing act? And how in the hell can this be beneficial? -- https://mail.python.org/mailman/listinfo/python-list
Re: Tabbed IDLE (was PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"!)
On 2014-07-20 23:40, Irmen de Jong wrote: > > And since IDLE is not a "tabbed editor", only *1* document > > is going to be displayed at a time. > > False. Idle opens any number of documents at the same time just > fine (in different windows - rather than tabs). This sounds like a failing of the OP's window-manager. Fluxbox lets me combine any number of windows into a tabbed interface, so IDLE *is* a tabbed editor on my machine (just like the Gimp). Moreover, it can even include other windows, so I just pulled together a tabbed IDLE interface that also has a terminal for interacting with git, a file-manager window for project management, and a mail window (because Zawinski's law[1]). ;-) -tkc [1] """ Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can. """ . -- https://mail.python.org/mailman/listinfo/python-list
Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"!
On 2014-07-20 19:06, Rick Johnson wrote: > > STEPS TO REPRODUCE BUG 1: "Attack of the clones!" > > > 1. Open the IDLE application > 2. Maximize the window that appears > 3. Go to the "File Menu" and choose the "Open" command > > Now repeat step 3 at least one more time, but feel free to > keep opening new dialogs until your fingers bleed and/or > eyes pop out. In the versions of IDLE that I have here (2.7.3 and 3.2.3), both prevent me from repeating step #3 multiple times. > > STEPS TO REPRODUCE BUG 2: "Hide and go seek!" > > > 1. Open the IDLE application > 2. Maximize the window that appears > 3. Go to the "File Menu" and choose the "Open" command > 4. Without disturbing the dialog, minimize the main window > 5. Using the taskbar icon, maximize the window > > Where is the dialog? Right where I left it? Are you running with a broken window manager that prevents you from seeing the dialog? Sure, because I activated the main IDLE window, it covers the dialog, but I can just select the Open dialog in my task-bar and it pops to the top (alternatively, I could have it display at a higher layer to prevent it from getting covered by the main IDLE window). This is the behavior I want and expect (I often want to refer to text in one window to inform my decisions in a modal window). I've got it running under Fluxbox on Debian Stable and it does exactly what I want/expect. -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"!
On Mon, Jul 21, 2014 at 12:06 PM, Rick Johnson wrote: > STEPS TO REPRODUCE BUG 1: "Attack of the clones!" > > 1. Open the IDLE application > 2. Maximize the window that appears > 3. Go to the "File Menu" and choose the "Open" command > > Now repeat step 3 at least one more time, but feel free to > keep opening new dialogs until your fingers bleed and/or > eyes pop out. > > Okay, now tell us, in what manner can an "interface bug" > like this be "beneficial"? You call it a bug because you can't think of any way it could be beneficial. That's the wrong way of looking at it. Something isn't a bug because you find it annoying; it's a bug because it fails to implement the programmer's intentions and/or the docs/specification. Opening multiple dialogs is *often* useful. The extras don't conflict, and you can open multiple files, so why should it be prevented? > STEPS TO REPRODUCE BUG 2: "Hide and go seek!" > > 1. Open the IDLE application > 2. Maximize the window that appears > 3. Go to the "File Menu" and choose the "Open" command > 4. Without disturbing the dialog, minimize the main window > 5. Using the taskbar icon, maximize the window > > Where is the dialog? How will you retrieve it *WITHOUT* > reducing the size of the window? And even if you are smart > enough to "intuit" what happened to the dialog, and how to > retrieve it, how will a noobie "intuit" such a disappearing > act? And how in the hell can this be beneficial? I'm not sure what platform you're on, and this depends a lot on your window manager. I'm guessing you may be on Windows, as Linux people are more likely to be aware of what DE/WM they use, so I tried it out on Windows. The file dialog appears in the alt-tab list, which seems perfectly sane and sensible, and in fact alt-tab is the most logical way to move between maximized windows anyway. This is not an Idle bug at all. It's a window manager issue. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"!
[snipped to bits] On 21/07/2014 03:38, Chris Angelico wrote: On Mon, Jul 21, 2014 at 12:06 PM, Rick Johnson wrote: STEPS TO REPRODUCE BUG 1: "Attack of the clones!" This is not an Idle bug at all. It's a window manager issue. ChrisA Attack of the clown? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Idle open file dialogs (was ...)
On 7/20/2014 5:14 PM, Rick Johnson wrote: Idle's Open file dialog is not modal. More than one can be open at one time. The all open as the same place. They can all be hidden by other windows, including the parent, especially if the parent is full screen. These might or might not be design bugs, I do not know that any are implementation bugs. They are definitely minor issues compared to some other Idle issues. Modal dialogs *MUST* be limited to a "one dialog at a time" These are not modal. If for some reason IDLE is not using the tkFileDialogs, Easily investigated from within Idle itself, using Find in Files Alt+F3 to search for tkFileDialog in idlelib, which became tkinter.filedialog in 3.x. Searching 'tkFileDialog' in lib/idlelib/*.py ... lib/idlelib\IOBinding.py: 7: import tkinter.filedialog as tkFileDialog lib/idlelib\IOBinding.py: 496: self.opendialog = tkFileDialog.Open(master=self.text, lib/idlelib\IOBinding.py: 516: self.savedialog = tkFileDialog.SaveAs( lib/idlelib\configHelpSourceEdit.py: 8: import tkinter.filedialog as tkFileDialog lib/idlelib\configHelpSourceEdit.py: 94: opendialog = tkFileDialog.Open(parent=self, filetypes=filetypes) Hits found: 5 (Hint: right-click to open locations.) As the output says, a right click will take one to the usage sites. # The following code proves that Tkinter filedialogs are # behaving in expected manners (properly placed as children # of the windows which "own" them, and following normal # focus patterns of "child windows" -- therfore, the problem # *MUST* be an IDLE problem. # # Tested on Python 2.7.8 # import Tkinter as tk from tkFileDialog import askopenfilename, asksaveasfilename class App(tk.Tk): def __init__(self): tk.Tk.__init__(self) self._createMenus() def _createMenus(self): menubar = tk.Menu(self) self.config(menu=menubar) filemenu = tk.Menu(menubar) menubar.add_cascade(label='File', menu=filemenu) filemenu.add_command(label='Open', command=self.requestOpenDialog) filemenu.add_command(label='Save As', command=self.requestSaveAsDialog) def _requestFileDialog(self, func, **kw): path = func(**kw) return path def requestOpenDialog(self, **kw): return self._requestFileDialog(askopenfilename, **kw) def requestSaveAsDialog(self, **kw): return self._requestFileDialog(asksaveasfilename, **kw) if __name__ == '__main__': app = App() app.mainloop() I will save this to look at some time. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"!
On 7/20/2014 10:38 PM, Chris Angelico wrote: on Windows. The file dialog appears in the alt-tab list, which seems perfectly sane and sensible, and in fact alt-tab is the most logical way to move between maximized windows anyway. Thank you for the fact, and the suggestion. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"!
On Mon, Jul 21, 2014 at 1:05 PM, Terry Reedy wrote: > On 7/20/2014 10:38 PM, Chris Angelico wrote: > >> on Windows. The file dialog appears in the alt-tab list, which seems >> perfectly sane and sensible, and in fact alt-tab is the most logical >> way to move between maximized windows anyway. > > > Thank you for the fact, and the suggestion. Not sure what suggestion you mean there, as I didn't think I was making any, but... sure. You're welcome! ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Idle's Shell: prompts and indents (was ...) Idle users please read
On 7/20/2014 8:55 PM, Chris Angelico wrote:
Idea 4 (which I already suggested on the tracker). Put statement input
prompts and output separators on lines by themselves. As with 3. above, use
standard 4 space indents, as with
:
def f(x):
if x:
print('got it')
return 'something'
:
f(3)
---
got it
:
Idle users other than Rick, any comments on the possible improvements?
Note that single multiline statements can be directly copied for pasting
by the normal method.
I can't comment on how it interacts with the editor half of Idle, but
for the shell as a stand-alone app, and for copying and pasting into
other programs, this last idea is rather interesting. I'm broadly
happy with the current system (>>> def f(x):), and the prompt is a
little weird (">>>:"? but maybe "Python:" would be less weird; I don't
advise "Idle:" as it implies that something is idle that might be
busy), but this would make copy/paste that bit easier. It would tend
to de-emphasize the difference between input and output, though, which
may or may not be an issue. But definitely interesting.
The prompt and separator could be configurable.
A few users have noticed (and complained) that setting sys.ps1 and
sys.ps2 *in the batch mode user process* has no effect. The Idle doc
should better explain why this is and should be. User code should not
affect the operation of Idle. Idle is separately configured through dialogs.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: Idle's Shell: prompts and indents (was ...) Idle users please read
On Mon, Jul 21, 2014 at 1:28 PM, Terry Reedy wrote: > A few users have noticed (and complained) that setting sys.ps1 and sys.ps2 > *in the batch mode user process* has no effect. The Idle doc should better > explain why this is and should be. User code should not affect the > operation of Idle. Idle is separately configured through dialogs. As I understand it, setting them has *absolutely* no effect, currently, right? There's no situation in which it would be useful to set them? In that case, it might be useful to put some magic in there (although I'm not sure it's possible; can't use @property at top level in a module) that gives a notification - pointing users to the dialog. No idea how you'd go about it, but telling someone when what s/he does is useless can be helpful. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Idle's Shell: prompts and indents (was ...) Idle users please read
On 7/20/2014 9:22 PM, Rick Johnson wrote: On Sunday, July 20, 2014 4:52:36 PM UTC-5, Terry Reedy wrote: The *real* problem is that the "interactive events" of the "editor window" and the "interactive events" of the "shell window" are far too tightly integrated with one another. I myself appreciate the finger saving principles of "DRY", however, sometimes, two distinct functionalities just cannot be implemented *IN A CLEAR MANNER* without repeating *some* of the code. We need to understand that IDLE is split into two distinct "modes", if you will -- the "interactive shell" and the "editor window". Attempting to use the same code to handle keystrokes for the shell *AND* the editor is a stumbling block to extending this mess. Slightly simplifying, the shell window and output windows are subclasses of the current editor window. I have thought about making all three inherit from a base interactive window. This would be a bit cleaner than the current design. I am not convinced of the need for more drastic change. Ideas don't count until recorded on the tracker. Which, as I reported back here, is why I promptly included both your OutputUndo idea and suggestion for a separate event and shortcut key in a new issue on the tracker. Hmm, okay. Saimadhav has locked together a thin canvas with the text for line numbers. It works in all my texts. I am just waiting for him to try it with a thin text instead. If you know some secret you think he missed. please describe it here. How can i offer improvements if i don't know where to find the code? http://bugs.python.org/issue17535 And besides, if my comments here "don't count" The ideas that I think are worth preserving and that I think are appropriate for the tracker I will put on the tracker. You can comment directly on the tracker yourself, but you would have to moderate your style. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: usenet reader software
On 2014-07-20, Chris Angelico wrote: > Ctrl-X in Angband, Ah-HAH! I've been trying to remember what the name was of an old CLI game that I used to play via a dialup ssh connection (using PuTTY) to a Panix.com account (they ran on NetBSD). Screen was my friend due to dropped connections, and I eventually moved from pine/pico to mutt/slrn/vim/bitchx (though to be honest I never warmed up to mutt all that much) until I got a Mac (OS X) and then later started dual-booting my PCs with Linux. Angband was the name of the game I played back then... sweet! -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: usenet reader software
On Mon, Jul 21, 2014 at 2:06 PM, Monte Milanuk wrote: > On 2014-07-20, Chris Angelico wrote: >> Ctrl-X in Angband, > > Ah-HAH! I've been trying to remember what the name was of an old CLI > game that I used to play via a dialup ssh connection (using PuTTY) to a > Panix.com account (they ran on NetBSD). Screen was my friend due to > dropped connections, and I eventually moved from pine/pico to > mutt/slrn/vim/bitchx (though to be honest I never warmed up to mutt all that > much) until I got a Mac (OS X) and then later started dual-booting my > PCs with Linux. Angband was the name of the game I played back then... sweet! Heh. I still have, sitting around, a modified Angband - which I did before I knew about source control, so it'd be a bit of a pain to try to rebase my changes onto a newer build. It has a whole lot of UI improvements, a new character class, a few new races (they're easy), a new gear slot, racial abilities, and a bunch of smaller features that don't come to mind right now. I should clean it up and throw it onto Github or something. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: usenet reader software
Sturla Molden writes: > wrote: > >> That doesn't address the problem at all! :-) You still need a news >> reader. > > The problem was that Thunderbird does not support killfiles when used as a > newsreader. Leafnode adds filtering capabilities which Thunderbird > (supposedly) does not have. > There are plenty of non-Thunderbird news clients... -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: usenet reader software
I'm trying gnus again, and immediately see the beauty of it. Actually Usenet is fast and commercial free, and easier to secure from prying NSA etc al (?) so maybe it will receive a general revival eventually. /martin s On 21 Jul 2014, Paul Rudin wrote: >Sturla Molden writes: > >> wrote: >> >>> That doesn't address the problem at all! :-) You still need a news >>> reader. >> >> The problem was that Thunderbird does not support killfiles when used >as a >> newsreader. Leafnode adds filtering capabilities which Thunderbird >> (supposedly) does not have. >> > >There are plenty of non-Thunderbird news clients... -- Sent with K-@ Mail - the evolution of emailing.-- https://mail.python.org/mailman/listinfo/python-list
