crossed, so you can ignore my response. Let's spend
our time implementing the PEPs as they stand, then see what else we
can do with the new APIs.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev
how theoretically better it
is.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
them into the PEP.
My apologies to Jason for missing the point he was making; thanks to
Nick for getting it and turning it into a productive change proposal.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http
. That way, everybody can help out (and it may motivate
more people).
Even if this is a temporary regression (e.g. PEP 342), it might be
worth it -- but only if there are at least two people committed to
help out quickly when there are problems.
--
--Guido van Rossum (home page: http
going to make this thing easier (not
with several more language changes approved: with-statement, extended
import, what else...)
What does the AST team think?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python
I will, if you tell me your sourceforge username.
On 10/7/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Could one of the Sourceforge powers-that-be grant me check in access so I can
update PEP 343 directly?
--
--Guido van Rossum (home page: http://www.python.org/~guido
though (1) is an int but
(1,) is a tuple.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
was expecting at least one line of output from
python at all times, but on most systems it is completely silent when
the input is empty. I fixed the test (also in 2.4) to allow empty
input as well as input ending in \n.
--
--Guido van Rossum (home page: http://www.python.org/~guido
return X into yield X;
return as someone previously proposed. :)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
Guido van Rossum wrote:
Before we do this I'd like to see you show some programming examples
that show how this would be used. I'm having a hard time understanding
where you would need this but I realize I haven't used this paradigm
enough to have a good feel for it, so I'm open
.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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
? is
it ready yet?).
I urge you to leave well enough alone. There's room for extensions
after people have built real systems with the raw material provided by
PEP 342 and 343.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev
the responses I'd say there's at most lukewarm
interest (including from me). You might also want to drop it and just
add it to your personal (or Zope's) library.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python
would help -- find places in the
standard library where this would make code more
readable/maintainable.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
On 10/10/05, Nick Coghlan [EMAIL PROTECTED] wrote:
I'm starting to think we want to let PEP 342 bake for at least one release
cycle before deciding what (if any) additional behaviour should be added to
generators.
Yes please!
--
--Guido van Rossum (home page: http://www.python.org/~guido
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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
. If you ignore priorities, all your threads
default to the same priority, so there's no preemption.
If you want a thread that can preempt others, you give
it a higher priority.
If you ask me, priorities are worse than the problem they are trying to solve.
--
--Guido van Rossum (home page: http
uncomfortable that you have to write
f(a, b, foo=1, bar=2, *args, **kwds)
I've always wanted to write that as
f(a, b, *args, foo=1, bar=2, **kwds)
but the current grammar doesn't allow it.
Still -0 on the whole thing,
--
--Guido van Rossum (home page: http://www.python.org/~guido
have a feeling
it's not that common.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
of the script that was used to
invoke python (sys.argv[0], typically). If there is no script, or it
is being read from stdin, the default is ''.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
did
so I'm not sure what he saw.
I see what you see. The first entry is the script's directory, the
2nd is a nonexistent zip file, the 3rd is the current directory, then
the rest is standard library stuff.
I suppose PC/getpathp.c puts it there, per your post quoted above?
--
--Guido van Rossum
the same state no matter which
API is used; and in fact the setblocking() API is redundant.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
the same but different case is bad style.
(I'd suggest queueing.Queue except nobody can type that right. :)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
On 10/12/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Is the Queue class very useful outside a multithreaded context?
No. It was designed specifically for inter-thread communication.
--
--Guido van Rossum (home page: http://www.python.org/~guido
On 10/12/05, Aahz [EMAIL PROTECTED] wrote:
(Python 3.0
should deprecate ``thread`` by renaming it to ``_thread``).
+1. (We could even start doing this before 3.0.)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev
underscore.
Could you specify exactly what you have in mind? How would backwards
compatibility be maintained in 2.x?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
On 10/13/05, Fredrik Lundh [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
BTW, Queue.Queue violates a recent module naming standard; it is now
considered bad style to name the class and the module the same.
Modules and packages should have short all-lowercase names, classes
should
that might arise.
Then Lock, RLock, Semaphore, etc belong there instead of in threading don't
they?
No. Locks and semaphores are the lowest-level threading primitives.
They go in the basic module.
--
--Guido van Rossum (home page: http://www.python.org/~guido
[Jeremy]
Neil and I have been working on the AST branch for the last week.
We're nearly ready to merge the changes to the head.
[Raymond]
Nice work.
Indeed. I should've threatened to kill the AST branch long ago! :)
--
--Guido van Rossum (home page: http://www.python.org/~guido
Sobebody help Nick! This is beyond my SF-fu! :-(
On 10/15/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
You're in. Use it wisely. Let me know if there are things you still
cannot do. (But I'm not used to being SF project admin any more; other
admins may be able to help
With Neal's help I've fixed Nick's permissions. Enjoy, Nick!
On 10/15/05, Guido van Rossum [EMAIL PROTECTED] wrote:
Somebody help Nick! This is beyond my SF-fu! :-(
On 10/15/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
You're in. Use it wisely. Let me know
currently says yes)
I hope you reverted the status to Proposed...
On the latter: I think it shouldn't; I don't like this kind of magic.
I'll have to read it before I can comment on the rest.
--
--Guido van Rossum (home page: http://www.python.org/~guido
typing (and certainly less indenting!). Just write this:
class C:
def getFoo(self): ...
def setFoo(self): ...
foo = property(getFoo, setFoo)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing
On 10/16/05, Calvin Spealman [EMAIL PROTECTED] wrote:
On 10/16/05, Guido van Rossum [EMAIL PROTECTED] wrote:
Nick, and everybody else trying to find a solution for this
problem, please don't. There's nothing wrong with having the three
accessor methods explicitly in the namespace, it's
in the
context of renaming operations, e.g.:
getx = lambda self: 42
def sety(self, value): self._y = value
setx = sety
x = LateBindingProperty(getx, setx)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing
right, because the module can't
decide whether it behaves like a class or like an instance. Also the
direct access to global variables prevents you to put any kind of code
in the get-attribute path.
--
--Guido van Rossum (home page: http://www.python.org/~guido
On 10/17/05, Jim Jewett [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
Another idea might be to change the exec() spec so that you are
required to pass in a namespace (and you can't use locals() either!).
Then the whole point becomes moot.
I think of exec as having two major uses:
(1
do you think?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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
', and D doesn't override getx, so D().y calls C.getx() instead
of D.gety().
If you can think of a solution that looks better than mine, you're a genius.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev
...
which would somehow translate into code similar to your recipe.
But until then, I prefer the simplicity of
foo = property('get_foo', 'set_foo')
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev
lambda arg: getattr(arg, name)
xyzzy = XYZZY()
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
is fine with me. :-)
Also, Nick wants the name 'context' for PEP-343 style context
managers. I think it's overloading too much to use the same word for
per-thread or per-coroutine context.
--
--Guido van Rossum (home page: http://www.python.org/~guido
On 10/20/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 04:04 PM 10/20/2005 -0400, Jeremy Hylton wrote:
On 10/20/05, Guido van Rossum [EMAIL PROTECTED] wrote:
Whoa, folks! Can I ask the gentlemen to curb their enthusiasm?
PEP 343 is still (back) on the drawing table, PEP 342 has barely
On 10/20/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 08:57 AM 10/20/2005 -0700, Guido van Rossum wrote:
Whoa, folks! Can I ask the gentlemen to curb their enthusiasm?
PEP 343 is still (back) on the drawing table, PEP 342 has barely been
implemented (did it survive the AST-branch merge
.func_code.co_varnames,
+ ('two', '.1', 'compound', 'argument', 'list'))
This doesn't bother me.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
a reimplementation of pgen in
Python. This also includes a nifty way to generate ASTs. This should
become available within a few weeks.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http
the
thread to idle-dev where it seems that his issues with the
contribution are being resolved and a fork is averted. Whew!
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
agree that was a bad idea?
Agreed.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
self
finally:
self.close()
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
such a
method wouldn't be a generator), it's exceedingly subtle for the human
reader. I'd much rather see the @contextmanager decorator to emphasize
the difference.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
invokes in order to create a new class.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman
no to both proposals and the worries cancel each
other out. EIBTI.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
.)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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
it at that.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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
str is unlikely to
work for you because then too many places are going to assume the
internal representation is also the same as for str.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
On 10/24/05, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
A concern I'd have with fixing this is that Unicode objects also
support the buffer API. In any situation where either str or unicode
is accepted I'd be reluctant to guess whether a buffer object was
meant
character buffer data type without
direct indexing?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
On 10/24/05, Martin v. Löwis [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
Changing the APIs would be much work, although perhaps not impossible
of Python 3000. For example, Raymond Hettinger's partition() API
doesn't refer to indices at all, and can replace many uses of find
. :-)
Did they tell you what they were trying to do that MacPython 2.4.2
wouldn't let them, beyond represent a large Unicode string as an
array of 4-byte integers?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
On 10/25/05, Eric Nieuwland [EMAIL PROTECTED] wrote:
Hmmm... Would it be reasonable to introduce a ProtocolError exception?
And which perceived problem would that solve? The problem of Nick
Guido disagreeing in public?
--
--Guido van Rossum (home page: http://www.python.org/~guido
good -- you'll have to
learn about what __exit__ is and where it is required.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
is to track down Jim Hugunin and see if he remembers.
He's jimhug at microsoft.com or jim at hugunin.net.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
On 10/25/05, Bill Janssen [EMAIL PROTECTED] wrote:
I think he was more interested in the invariant Martin proposed, that
len(\U0001)
should always be the same and should always be 1.
Yes but why? What does this invariant do for him?
--
--Guido van Rossum (home page: http
it quite a while ago.
This is all after Jim was not involved with Jython anymore, Finn Bock
started this.
Oops! Sorry for the misinformation. Shows how much I know. :(
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev
in comments,
which I'd otherwise favor. What do Unicode-aware apps generally do
with right-to-left characters?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
all the time. :-)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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
to read this email, I and l are /identical/.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
).
Python 2.5 will be released some time next year; we hope to have
alphas available in the 2nd quarter. Thatr's about as firm as we can
currently be about the release date.
Enjoy,
--Guido van Rossum
On 10/25/05, Lucky Wankhede [EMAIL PROTECTED] wrote:
Dear sir,
I m a student
. I can work
with the pydotorg svn repository just fine (checked something in last
week).
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
to
get the correct value (None) into ex.message.
Since ex.message is new, how can you say that it should have the value
None? IMO the whole idea is that ex.message should always be a string
going forward (although I'm not going to add a typecheck to enforce
this).
--
--Guido van Rossum (home page
conforming code can catch exceptions raised by not-yet conforming code.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
contain 'return' but not 'return value'. I think
that irkedness is unwarranted; 'return' is useful to cause an early
exit, but generators don't have a return value so 'return value' is
meaningless.
--
--Guido van Rossum (home page: http://www.python.org/~guido
I've made a final pass over PEP 352, mostly fixing the __str__,
__unicode__ and __repr__ methods to behave more reasonably. I'm all
for accepting it now. Does anybody see any last-minute show-stopping
problems with it?
As always, http://python.org/peps/pep-0352.html
--
--Guido van Rossum (home
this by rewriting the fields as $Revision$ and $Date$
but that doesn't seem to make a difference.
Googling for this is a bit tricky because Google collapses $Revision
and Revision, which makes any query for svn and $Revision rather
non-specific. :-( It's also not yet in our Wiki.
--
--Guido van
to
be finished, i.e.:
* One of the global variable speedup PEPs
* Guido's instance variable speedup idea (LOAD_SELF_IVAR and
STORE_SELF_IVAR, see
http://mail.python.org/pipermail/python-dev/2002-February/019854.html)
--
--Guido van Rossum (home page: http://www.python.org/~guido
On 11/1/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 10:22 AM 11/1/2005 -0700, Guido van Rossum wrote:
* PEP 328 - absolute/relative import
I assume that references to 2.4 in that PEP should be changed to 2.5, and
so on.
For the part that hasn't been implemented yet, yes.
It also appears
On 11/1/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 11:14 AM 11/1/2005 -0700, Guido van Rossum wrote:
I guess this ought to be recorded. :-(
The issue has been beaten to death and my position remains firm:
rather than playing namespace games, consistent renaming is the right
thing to do
much more
potential.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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
?)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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
/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
[Guido van Rossum]
I've made a final pass over PEP 352, mostly fixing the __str__,
__unicode__ and __repr__ methods to behave more reasonably. I'm all
for accepting it now. Does anybody see any last-minute show-stopping
problems with it?
[François]
I did not follow the thread, so maybe
up.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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
be
considered equal.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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
On 11/6/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 12:58 PM 11/6/2005 -0800, Guido van Rossum wrote:
The main way this breaks down is when comparing objects of different
types. While most comparisons typically are defined in terms of
comparisons on simpler or contained objects, two objects
by default. All of this
is Python 3000 only.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman
/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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
[EMAIL PROTECTED] wrote:
On 11/9/05, Guido van Rossum [EMAIL PROTECTED] wrote:
You didn't show us what's in the zip file. Can you show a zipinfo output?
$ zipinfo modules.zip
Archive: modules.zip 426 bytes 2 files
-rw-r--r-- 2.3 unx 109 bx defN 31-Oct-05 14:49 module_o.pyo
-rw-r--r
you're looking for is a customizable factory fuction.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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
On 11/9/05, Brett Cannon [EMAIL PROTECTED] wrote:
On 11/9/05, Guido van Rossum [EMAIL PROTECTED] wrote:
Maybe it makes more sense to deprecate .pyo altogether and instead
have a post-load optimizer optimize .pyc files according to the
current optimization settings?
But I thought part
On 11/9/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 03:25 PM 11/9/2005 -0800, Guido van Rossum wrote:
The only solutions I can think of that use a single file actually
*increase* the file size by having unoptimized and optimized code
side-by-side, or some way to quickly skip the assertions
Phillip's suggestion -- no new opcode, just a conditional jump
that can be easily optimized out.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
possibility, good if we had backwards compatibility
requirements for bytecode -- which we don't, fortunately :-).
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
On 11/9/05, Brett Cannon [EMAIL PROTECTED] wrote:
On 11/9/05, Guido van Rossum [EMAIL PROTECTED] wrote:
I like Phillip's suggestion -- no new opcode, just a conditional jump
that can be easily optimized out.
Huh? But Phillip is suggesting a new opcode that is essentially
-sequitur if I ever saw one. Who gave you that idea? There
is no connection.
(If there's *any* reason for Python not having a standard event loop
it's probably because I've never needed one.)
--
--Guido van Rossum (home page: http://www.python.org/~guido
On 11/10/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 04:33 PM 11/9/2005 -0800, Guido van Rossum wrote:
On 11/9/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
By the way, while we're on this subject, can we make the optimization
options be part of the compile() interface? Right now
. While
there are ways to cache bytecode without having multiple extensions,
we probably can't do that until Python 3.0.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http
ValueError: I/O operation on closed file.
Should they raise the same exception? Should this be fixed for 2.5?
I think cStringIO is doing the right thing; real files behave the same way.
Submit a patch for StringIO (also docs please) and assign it to me and
I'll make sure it goes in.
--
--Guido van
401 - 500 of 5880 matches
Mail list logo
