Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Bad idea, as several pointed out -- quit() should return a 0 exit
> to the shell.
I like the idea of making "quit" callable. One small concern I have
is that people will use it in scripts to exit (rather than one of
the other existing ways to exit).
I think it would be a good idea to follow the Plone project and try
to encourage new developers by offering assistance to get them up
and running. AFAIK, we've done that for the other bug days but it
might help to publish the fact that no prior Python development
experience is necessary.
Neil
Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Not even True and False.
>
> I don't see why everything that doesn't make sense to be shadowed
> ought to become a keyword. That way lies madness.
Have you considered whether P3K will disallow names from being
shadowed in such as way as to prevent the
Guido van Rossum <[EMAIL PROTECTED]> wrote:
> This would require a bit "__del__ already called" on an object,
> but don't we have a whole word of GC-related flags?
No.
Neil
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mail
Greg Ewing <[EMAIL PROTECTED]> wrote:
> Okay, so would it be possible for a generator that
> needs finalisation to set up a weakref callback, suitably
> rooted somewhere so that the callback is reachable,
> that references enough stuff to clean up after the
> generator, without referencing the gene
Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> Most other languages that support lexical scoping (including Scheme,
> JavaScript, Ruby, Perl, E, Java, Smalltalk) provide a uniform way
> to read and write to scopes at all levels. This is done by letting
> programmers specify the scope in which they want
ision: 1.2 $
Last-Modified: $Date: 2005/08/06 04:05:48 $
Author: Neil Schemenauer <[EMAIL PROTECTED]>
Status: Draft
Type: Standards Track
Content-Type: text/plain
Created: 02-Aug-2005
Post-History: 06-Aug-2005
Python-Version: 2.5
Abstract
This PEP proposes the introduction of a new built-
On Sat, Aug 06, 2005 at 06:56:39PM -0700, Guido van Rossum wrote:
> My first response to the PEP, however, is that instead of a new
> built-in function, I'd rather relax the requirement that str() return
> an 8-bit string
Do you have any thoughts on what the C API would be? It seems to me
that Py
On Sat, Aug 06, 2005 at 06:56:39PM -0700, Guido van Rossum wrote:
> My first response to the PEP, however, is that instead of a new
> built-in function, I'd rather relax the requirement that str() return
> an 8-bit string -- after all, int() is allowed to return a long, so
> why couldn't str() be a
I've been getting:
ssh: connect to host cvs.sourceforge.net port 22: Connection refused
for the past few hours. Their "Site News" doesn't say anything
about downtime.
Neil
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
On Sat, Aug 13, 2005 at 02:27:22PM -0700, Guido van Rossum wrote:
> What do people think of using this for Python?
I think it deserves consideration. One idea would be to have a
Bazaar-NG repository that tracks the CVS SF repository. I haven't
tried it yet but there is a tool called Tailor[1] th
On Sat, Aug 13, 2005 at 06:00:37PM -0500, [EMAIL PROTECTED] wrote:
> Based on the message Guido forwarded, I installed bazaar-ng. From Mark's
> note it seems they convert cvs repositories to bzr repositories, but I
> didn't see any mention in the bzr docs of any sort of cvs2bzr tool.
Haven't trie
On Sun, Aug 14, 2005 at 06:16:11PM +0200, "Martin v. Löwis" wrote:
> It depends on what "a bit" is. Waiting a month would be fine; waiting
> two years might be pointless.
It looks like the process of converting a CVS repository to
Bazaar-NG does not yet work well (to be kind). The path
CVS->SVN->
On Sat, Aug 13, 2005 at 06:03:46PM -0600, Neil Schemenauer wrote:
> Haven't tried it but should work:
>
> http://darcs.net/DarcsWiki/Tailor
After applying the attached patch, this command seemed to work for
converting the initial revision:
~/src/cvsync/tailor.py --source-kin
On Tue, Aug 16, 2005 at 08:31:20PM +0200, "Martin v. Löwis" wrote:
> I would agree. However, there still is the debate of hosting the
> repository elsehwere. Some people (Anthony, Guido, Tim) would prefer
> to pay for it, instead of hosting it on svn.python.org.
Another option would be to pay some
On Wed, Aug 17, 2005 at 06:37:11PM +0200, Reinhold Birkenfeld wrote:
> As I can see, this is not going to happen before Py3k, as it is completely
> breaking backwards compatibility. As such, a PEP would be unnecessary.
We could add sys.id for 2.5 and remove __builtin__.id a some later
time (e.g. f
applications and
report any incompatibilities.
PEP: 349
Title: Allow str() to return unicode strings
Version: $Revision: 1.3 $
Last-Modified: $Date: 2005/08/22 21:12:08 $
Author: Neil Schemenauer <[EMAIL PROTECTED]>
Status: Draft
Type: Standards Track
Content-Type: text/plain
Created: 02-Aug-200
On Tue, Aug 23, 2005 at 10:46:36AM +0200, Wolfgang Lipp wrote:
> one point i don't seem to understand right now is why it says in the
> function definition::
>
> if type(s) is str or type(s) is unicode:
> ...
>
> instead of using ``isinstance()``.
I don't think isinstance() would b
On Tue, Aug 23, 2005 at 11:43:02AM -0400, Phillip J. Eby wrote:
> At 09:21 AM 8/23/2005 -0600, Neil Schemenauer wrote:
> >> then of course, one could change ``unicode.__str__()`` to return
> >> ``self``, itself, which should work. but then, why so complicated?
> >
>
On Tue, Aug 23, 2005 at 05:45:27PM +0200, Wolfgang Lipp wrote:
> i have to revise my last posting -- exporting the new ``str``
> pure-python implementation breaks -- of course! -- as soon
> as ``isinstance(x,str)`` [sic] is used
Right. I tried to come up with a pure Python version so people
could
On Thu, Aug 25, 2005 at 11:58:48AM -0400, Raymond Hettinger wrote:
> Deprecation is only warranted if the interim substitute works --
> AFAICT, there is no other way to broadly catch exceptions not
> derived from Exception.
This seems to get to the heart of the problem. I'm no fan of bare
excepts
On Wed, Aug 24, 2005 at 09:11:18PM +0200, Dieter Maurer wrote:
> Neil Schemenauer <[EMAIL PROTECTED]> writes on Mon, 22 Aug 2005 15:31:42
> -0600:
> > The code was fixed by changing
> > the line "header = str(header)" to:
> >
&
On Fri, Aug 26, 2005 at 06:21:58PM +0200, Alain Poirier wrote:
> For example, I often use this class to help me in functional programming :
>
> _marker = ()
[...]
You should not use an immutable object here (e.g. the empty tuple is
shared). My preferred idiom is:
_marker = object()
Cheer
Micah Elliott <[EMAIL PROTECTED]> wrote:
> ``FIXME (XXX, DEBUG, BROKEN, REFACTOR, REFACT, RFCTR, OOPS, SMELL, NEEDSWORK,
> INSPECT)``
>*Fix me*: Areas of problematic or ugly code needing refactoring or
>cleanup.
I think the standard should not have codetags that are synonyms.
This is Pyth
Nick Coghlan <[EMAIL PROTECTED]> wrote:
> If we kill the branch for now, then anyone that wants to bring up the idea
> again can write a PEP first
I still have some (very) small hope that it can be finished. If we
don't get it done soon then I fear that it will never happen. I had
hoped that a
On Thu, Oct 13, 2005 at 05:08:41PM -0500, [EMAIL PROTECTED] wrote:
> test_trace segfaults consistently, even when run alone.
That's a bug in frame_setlineno(), IMO. It's failing to detect an
invalid jump because the lnotab generated by the new compiler is
slightly different (DUP_TOP opcode corres
On Fri, Oct 14, 2005 at 01:03:28AM -0400, Raymond Hettinger wrote:
> Do the AST branch generate a syntax error for:
>
>foo(a = i for i in range(10))
No. It generates the same broken code as the current compiler.
Neil
___
Python-Dev mailing list
Anthony Baxter <[EMAIL PROTECTED]> wrote:
> Could someone involved give a short email laying out what concrete (no
> pun intended) advantages this new compiler gives us?
One advantage is that it decreases the coupling between the parser
and the backend of the compiler. For example, it should be p
Simon Burton <[EMAIL PROTECTED]> wrote:
> Is there a python interface ?
Not yet.
Neil
___
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
Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Thomas Lee wrote:
>
>> Even if it meant we had just one function call - one, safe function call
>> that deallocated all the memory allocated within a function - that we
>> had to put before each and every return, that's better than what we
>> have.
>
> all
Tim Peters <[EMAIL PROTECTED]> wrote:
> We should note that hotshot didn't intend to reduce total time
> overhead. What it's aiming at here is to be less disruptive (than
> profile.py) to the code being profiled _while_ that code is running.
A statistical profiler (e.g.
http://wingolog.org/archi
On Mon, Nov 28, 2005 at 03:47:07PM -0500, Jeremy Hylton wrote:
> The reason this thread started was the complaint that reference
> counting in the compiler is really difficult.
I don't think that's exactly right. The problem is that the AST
compiler mixes its own memory management strategy with r
Thomas Lee <[EMAIL PROTECTED]> wrote:
> Quick semi-related question: where are the marshal_* functions called?
> They're all static in Python-ast.c and don't seem to be actually called
> anywhere. Can we ditch them?
They are intended to be used to make the AST available to Python
code. It would
Neal Norwitz <[EMAIL PROTECTED]> wrote:
> If everything is a PyObject, wouldn't [the marshal functions] be
> redundant?
You could be right. Spending time to kept them working is probably
wasted effort.
Neil
___
Python-Dev mailing list
Python-Dev@pyt
On Tue, Dec 06, 2005 at 11:20:46AM +0100, Weber, Gregoire wrote:
> We're seriously evaluating Python for use in embedded realtime systems
> and need some informations about Pythons garbage collector.
>
> What we're interested mostly in the runtime behaviour of the GC. The
> main question is:
>
>
Armin Rigo <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 12, 2005 at 10:23:27PM +0100, Fredrik Lundh wrote:
>> $(AST_H) $(AST_C): $(AST_ASDL) $(ASDLGEN_FILES)
>> -$(PYTHON) $(ASDLGEN) $(AST_ASDL)
> The same just-ignore-it behavior can bite if the script genuinely fails
> after you just made a t
Armin Rigo <[EMAIL PROTECTED]> wrote:
> Of course, speaking of a rewrite, PyPy does the "right thing" in
> these two areas. Won't happen to CPython, though. There are too
> much backward-compatibility issues with the PyTypeObject
> structure; I think we're doomed with patching the bugs as they
>
Martin v. Löwis <[EMAIL PROTECTED]> wrote:
> One challenge is that PyObject_GC_Del doesn't know how large the memory
> block is that is being released. So it is difficult to find out how
> much memory is being released in the collection.
Another idea would be to add accounting to the PyMem_* inter
Scott David Daniels <[EMAIL PROTECTED]> wrote:
> Or, perhaps:
> class _Quitter(str):
> def __call__(self): raise SystemExit
> quit = _Quitter('The quit command. Type "quit()" to exit')
> exit = _Quitter('The exit command. Type "exit()" to exit')
FWIW, I like this kind of
Ian Bicking <[EMAIL PROTECTED]> wrote:
> OTOH, str(path) will break unicode filenames. And unicode()
> breaks anything that simply desires to pass data through without
> effecting its encoding.
That general problem was the motivation for PEP 349. Originally I
suggested adding a new built-in. Ho
Guido van Rossum <[EMAIL PROTECTED]> wrote:
> PEP 349 - str() may return unicode. Where is this?
Does that mean you didn't find and read the PEP or was it written so
badly that it answered none of your questions? The PEP is on
python.org with all the rest. I set the status to "Deferred"
because
201 - 241 of 241 matches
Mail list logo
