Hi, I need to select a text of text field! Which function is used for selection
of text of text field? Sonia,
> From: [EMAIL PROTECTED]> Subject: Python-Dev Digest, Vol 64, Issue 4> To:
> python-dev@python.org> Date: Mon, 3 Nov 2008 03:10:48 +0100> > Send
> Python-Dev mailing list submissions to> python-dev@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> [EMAIL PROTECTED]> > You can reach
> the person managing the list at> [EMAIL PROTECTED]> > 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.> ([EMAIL PROTECTED])> 5. Re: Fwd: Removal of GIL through
> refcounting removal.> (skip@
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 <[EMAIL
PROTECTED]>> Subject: Re: [Python-Dev] Fwd: Removal of GIL through refcounting>
removal.> To: python-dev@python.org> Message-ID: <[EMAIL PROTECTED]>>
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 de
struction (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" <[EMAIL PROTECTED]>>
Subject: Re: [Python-Dev] Fwd: Removal of GIL through refcounting> removal.>
To: "Eric Smith" <[EMAIL PROTECTED]>> Cc: python-dev@python.org> Message-ID:>
<[EMAIL PROTECTED]>> Content-Type: text/plain; charset=ISO-8859-1> > On Sun,
Nov 2, 2008 at 2:34 PM, Eric Smith <[EMAIL PROTECTED]> 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 Ols
en, aka Rhamphoryncus> > > ------------------------------> > Message: 3> Date:
Mon, 03 Nov 2008 11:33:11 +1300> From: Greg Ewing <[EMAIL PROTECTED]>> Subject:
Re: [Python-Dev] Fwd: Removal of GIL through refcounting> removal.> To:
python-dev@python.org> Message-ID: <[EMAIL PROTECTED]>> 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:
[EMAIL PROTECTED]> Subject: Re: [Python-Dev] Fwd: Removal of GIL through
refcounting> removal.> To: Antoine Pitrou <[EMAIL PROTECTED]>> Cc:
python-dev@python.org> Message-ID: <[EMAIL PROTECTED]>> 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: [EMAIL PROTECTED]> Subject: Re:
[Python-Dev] Fwd: Removal of GIL through refcounting> removal.> To: Eric Smith
<[EMAIL PROTECTED]>> Cc: python-dev@python.org> Message-I
D: <[EMAIL PROTECTED]>> 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" <[EMAIL PROTECTED]>> Subject: [Python-Dev] Looking
for VCS usage scenarios> To: "Python dev" <python-dev@python.org>> Message-ID:>
<[EMAIL PROTECTED]>> 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 P
EP. 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 <[EMAIL PROTECTED]>> Subject: Re: [Python-Dev] Fwd:
Removal of GIL through refcounting> removal.> To: [EMAIL PROTECTED]> Cc:
python-dev@python.org> Message-ID: <[EMAIL PROTECTED]>> Content-Ty
pe: text/plain; charset=ISO-8859-1; format=flowed> > [EMAIL PROTECTED] 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" <[EMAIL PROTECTED]>> Subject: Re: [Python-Dev]
Looking for VCS usage scenarios> To: "Brett Cannon" <[EMAIL PROTECTED]>> Cc:
Python dev <python-dev@python.org>> Message-ID:> <[EMAIL PROTECTED]>>
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 alre
ady> > 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 ta
ke 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 someth
ing 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" <[EMAIL PROTECTED]>> Subject: Re:
[Python-Dev] My patches> To: "Barry Warsaw" <[EMAIL PROTECTED]>> Cc: [EMAIL
PROTECTED], python-dev@python.org> Message-ID:> <[EMAIL PROTECTED]>>
Content-Type: text/plain; charset=ISO-8859-1> > On Sun, Nov 2, 2008 at 5:42 AM,
Barry Warsaw <[EMAIL PROTECTED]> 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@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
