[Python-Dev] How to select text of text field in python‏Card

[Sonia]

Hi, I need to select a text of text field! Which function is used for selection of text of text field? Sonia,
 
> From: python-dev-request at python.org> Subject: Python-Dev Digest, Vol 64, Issue 4> To: python-dev at python.org> Date: Mon, 3 Nov 2008 03:10:48 +0100> > Send Python-Dev mailing list submissions to> python-dev at python.org> > To subscribe or unsubscribe via the World Wide Web, visit> http://mail.python.org/mailman/listinfo/python-dev> or, via email, send a message with subject or body 'help' to> python-dev-request at python.org> > You can reach the person managing the list at> python-dev-owner at python.org> > When replying, please edit your Subject line so it is more specific> than "Re: Contents of Python-Dev digest..."> > > Today's Topics:> > 1. Re: Fwd: Removal of GIL through refcounting removal. (Eric Smith)> 2. Re: Fwd: Removal of GIL through refcounting removal. (Adam Olsen)> 3. Re: Fwd: Removal of GIL through refcounting removal. (Greg Ewing)> 4. Re: Fwd: Removal of GIL through refcounting removal.> (skip at pobox.com)> 5. Re: Fwd: Removal of GIL through refcounting removal.> (skip at pobox.com)> 6. Looking for VCS usage scenarios (Brett Cannon)> 7. Re: Fwd: Removal of GIL through refcounting removal. (Eric Smith)> 8. Re: Looking for VCS usage scenarios (Gustavo Niemeyer)> 9. Re: My patches (Alex Martelli)> > > ----------------------------------------------------------------------> > Message: 1> Date: Sun, 02 Nov 2008 15:34:14 -0500> From: Eric Smith <eric at trueblade.com>> Subject: Re: [Python-Dev] Fwd: Removal of GIL through refcounting> removal.> To: python-dev at python.org> Message-ID: <490E0EC6.1070404 at trueblade.com>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed> > Giovanni Bajo wrote:> > [[ my 0.2: it would be a great loss if we lose reference-counting > > semantic (eg: objects deallocated as soon as they exit the scope). I > > would bargain that for a noticable speed increase of course, but my own > > experience with standard GCs from other languages has been less than > > stellar. ]]> > And my $0.02:> > I'd gladly trade deterministic destruction (due to reference counting or > any other mechanism) for improved performance. I've often thought of > creating a mode where destruction didn't happen right away with > reference counting, just so I could find places where I'm relying on it. > I consider it a bug to rely on reference counting to close files, for > example. Maybe I should just run under Jython or IronPython everyone > once in a while.> > > ------------------------------> > Message: 2> Date: Sun, 2 Nov 2008 15:07:45 -0600> From: "Adam Olsen" <rhamph at gmail.com>> Subject: Re: [Python-Dev] Fwd: Removal of GIL through refcounting> removal.> To: "Eric Smith" <eric at trueblade.com>> Cc: python-dev at python.org> Message-ID:> <aac2c7cb0811021307j11aafb84i66eacfa55c23eaad at mail.gmail.com>> Content-Type: text/plain; charset=ISO-8859-1> > On Sun, Nov 2, 2008 at 2:34 PM, Eric Smith <eric at trueblade.com> wrote:> > Giovanni Bajo wrote:> >>> >> [[ my 0.2: it would be a great loss if we lose reference-counting semantic> >> (eg: objects deallocated as soon as they exit the scope). I would bargain> >> that for a noticable speed increase of course, but my own experience with> >> standard GCs from other languages has been less than stellar. ]]> >> > And my $0.02:> >> > I'd gladly trade deterministic destruction (due to reference counting or any> > other mechanism) for improved performance. I've often thought of creating a> > mode where destruction didn't happen right away with reference counting,> > just so I could find places where I'm relying on it. I consider it a bug to> > rely on reference counting to close files, for example. Maybe I should just> > run under Jython or IronPython everyone once in a while.> > I've considered making files issue a warning if they've got buffered> writes and they're not explicitly closed. Although my feeling is a> read-only file should produce the same warning, there's situations> where "proper" error handling is very difficult or impossible.> > > -- > Adam Olsen, aka Rhamphoryncus> > > ------------------------------> > Message: 3> Date: Mon, 03 Nov 2008 11:33:11 +1300> From: Greg Ewing <greg.ewing at canterbury.ac.nz>> Subject: Re: [Python-Dev] Fwd: Removal of GIL through refcounting> removal.> To: python-dev at python.org> Message-ID: <490E2AA7.4070206 at canterbury.ac.nz>> Content-Type: text/plain; charset=UTF-8; format=flowed> > Eric Smith wrote:> > > I'd gladly trade deterministic destruction (due to reference counting or > > any other mechanism) for improved performance.> > Another thing to consider is that refcounting spreads out the> time spent doing GC evenly over the execution of the program,> so that you don't get pauses occurring at random times.> > Sometimes in games I've found that I had to disable cyclic> GC in order to get smooth frame rates. With no refcounting> I wouldn't have the option of doing that. I'd be disappointed> if that meant I could no longer use Python for these kinds of> games.> > -- > Greg> > > ------------------------------> > Message: 4> Date: Sun, 2 Nov 2008 17:51:50 -0600> From: skip at pobox.com> Subject: Re: [Python-Dev] Fwd: Removal of GIL through refcounting> removal.> To: Antoine Pitrou <solipsis at pitrou.net>> Cc: python-dev at python.org> Message-ID: <18702.15638.223872.706216 at montanaro-dyndns-org.local>> Content-Type: text/plain; charset=us-ascii> > > Antoine> I think it is important to remind that the GIL doesn't prevent> Antoine> (almost) true multithreading. The only thing it prevents is> Antoine> full use of multi-CPU resources in a single process. > > I believe everyone here knows that. I believe what most people are> clamoring for is to make "full use of their multi-CPU resources in a single> process".> > Skip> > > ------------------------------> > Message: 5> Date: Sun, 2 Nov 2008 17:55:03 -0600> From: skip at pobox.com> Subject: Re: [Python-Dev] Fwd: Removal of GIL through refcounting> removal.> To: Eric Smith <eric at trueblade.com>> Cc: python-dev at python.org> Message-ID: <18702.15831.164083.97731 at montanaro-dyndns-org.local>> Content-Type: text/plain; charset=us-ascii> > > Eric> I consider it a bug to rely on reference counting to close files,> > We can mostly have our cake and eat it too using the "with" statement. In> most cases it should be sufficient I would think.> > Skip> > > > ------------------------------> > Message: 6> Date: Sun, 2 Nov 2008 16:05:56 -0800> From: "Brett Cannon" <brett at python.org>> Subject: [Python-Dev] Looking for VCS usage scenarios> To: "Python dev" <python-dev at python.org>> Message-ID:> <bbaeab100811021605o16bb60fapfbf30e9549e1a7c2 at mail.gmail.com>> Content-Type: text/plain; charset=UTF-8> > I have started the DVCS PEP which can be seen at> http://docs.google.com/Doc?id=dg7fctr4_40dvjkdg64 . Not much is there> beyond the rationale, usage scenarios I plan to use, and what other> sections I plan to write.> > At this point I am looking for any suggestions for fundamental usage> scenarios that I am missing from the PEP. If you think the few already> listed are missing some core part of a VCS, please let me know.> > And just to stave off some emails, I have two comments to make. One,> please do not start sending me info on how to fill in the usage> scenarios. I want to first solidify what the scenarios are. Plus I> want to figure them out on my own to get a feel of the documentation> for the tools.> > Second, as of right now Git is not in the running. Ignoring the fact I> dislike the tool (my issues with it are documented in the python-dev> archives), there is also the fact that it would be nicer to have> Python have as its VCS something written in Python instead of C/Perl.> > -Brett> > > ------------------------------> > Message: 7> Date: Sun, 02 Nov 2008 19:45:15 -0500> From: Eric Smith <eric at trueblade.com>> Subject: Re: [Python-Dev] Fwd: Removal of GIL through refcounting> removal.> To: skip at pobox.com> Cc: python-dev at python.org> Message-ID: <490E499B.9000703 at trueblade.com>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed> > skip at pobox.com wrote:> > Eric> I consider it a bug to rely on reference counting to close files,> > > > We can mostly have our cake and eat it too using the "with" statement. In> > most cases it should be sufficient I would think.> > True, and I meant to mention that. But unfortunately, my work projects > are stuck on 2.4 for the time being, so that doesn't help me much.> > Eric.> > > ------------------------------> > Message: 8> Date: Sun, 2 Nov 2008 23:08:11 -0200> From: "Gustavo Niemeyer" <gustavo at niemeyer.net>> Subject: Re: [Python-Dev] Looking for VCS usage scenarios> To: "Brett Cannon" <brett at python.org>> Cc: Python dev <python-dev at python.org>> Message-ID:> <643d90130811021708r5d39cc4bvf65fedea82395cc at mail.gmail.com>> Content-Type: text/plain; charset=ISO-8859-1> > Hi Brett,> > > At this point I am looking for any suggestions for fundamental usage> > scenarios that I am missing from the PEP. If you think the few already> > listed are missing some core part of a VCS, please let me know.> > As an initial disclaimer, I use bzr in my daily routine. That said,> I'm sending below a few mostly unbiased high-level ideas, just based> on useful ways we explore the DVCS-aspect on our normal daily> workflow.> > == Coordinated development with dependent features ==> > A variation on coordinated development, which is actually one of the> main motivators for DVCS. Branch A is evolving out of the mainline,> and it depends on a feature that is on branch B which is also not yet> integrated. Parallel development of both should be nicely supported.> I'm sure all DVCS will do that in a decent form, but figuring how this> works may be instructive and worth mentioning.> > == Centralization of feature-specific development ==> > That's a curious one when we're talking about distributed development,> isn't it? :-) Think about the following scenario: 5 people working> in parallel on a tricky feature which will take a while to get to the> mainline. Each developer works on a specific aspect of the feature> for a few hours/days in their own branch, and then merges to and from> what's considered as the feature-mainline. In essence, the problem is> that it's messy to just go towards the "everyone merges from everyone"> route when working in a common problem. We've found that being able> to use an svn-like approach for the *feature* mainline (a branch that> is shared by all defining the status quo) is a handy way to handle> that. I'm sure there are other approaches to solve the same problem,> but it's interesting to consider what they are for each tool since in> our experience the problem will show up eventually, and supporting it> nicely makes a big difference on the outcome.> > == Attaching of history-carrying diffs ==> > This one may feel weird as well, and I'm guessing some people might> react as "just send a URL to a branch". In practice, it is handy many> times to just attach something to the bug tracker, for instance. This> means that the "branch" is kept in the history of the bug. Also, with> something like this, someone external to the development process may> very easily provide his changes in the bug or in a mail without having> to set up any infrastructure/accounts/whatever at all to provide his> branch.> > > That's it for now. If I can think of any other use cases from our> routine that might serve as things to explore in such a comparison,> I'll let you know.> > -- > Gustavo Niemeyer> http://niemeyer.net> > > ------------------------------> > Message: 9> Date: Sun, 2 Nov 2008 19:10:45 -0700> From: "Alex Martelli" <aleaxit at gmail.com>> Subject: Re: [Python-Dev] My patches> To: "Barry Warsaw" <barry at python.org>> Cc: amk at amk.ca, python-dev at python.org> Message-ID:> <e8a0972d0811021810v5ebe0dbbl7ea7db5c4b097610 at mail.gmail.com>> Content-Type: text/plain; charset=ISO-8859-1> > On Sun, Nov 2, 2008 at 5:42 AM, Barry Warsaw <barry at python.org> wrote:> ...> > A dvcs means that people can publish their branches in a wide variety of> > ways. Trusted developers can push their branches to code.python.org.> > Non-core developers can use one of the free public dvcs branch hosting> > service. Industrious users can self-publish their branches. Anyone with> > BTW, if we go with hg, I recommend bitbucket.org as a "free public> (hg) hosting service" of choice -- Jesper (the owner and developer of> the site) is friendly and solicitous in his maintenance, the whole> site is quite OS-friendly in general (free "professional-level"> accounts and support for open-source projects which choose to host> there) and Python-friendly in particular (I gather the site's coded in> Python), and my experience there has been nothing short of excellent.> All it's missing is a simple code review tool like code.google.com's> or Rietveld, but Jesper's promised me he would integrate something to> that effect...> > > Alex> > > ------------------------------> > _______________________________________________> Python-Dev mailing list> Python-Dev at python.org> http://mail.python.org/mailman/listinfo/python-dev> > > End of Python-Dev Digest, Vol 64, Issue 4> *****************************************
_________________________________________________________________
Connect to the next generation of MSN Messenger 
http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20081103/f4162b42/attachment-0001.htm>