At 01:25 PM 2/17/2007 +0200, KoDer wrote:
C:\\Python25\\lib\\. contain *many* packages with .dll files - i can't
just zip it.
wxPython,pyOpenGL,PIL,tk and so on. On Fedora 6 more than 40% dirs of
/usr/lib/site-packages contained .so files. Some of them add dirs to path
(wx,PIL,Gtk,...).
I'm not
At 04:38 PM 2/16/2007 +0200, KoDer wrote:
'strace' command shows next: most of startup time the interpreter
try to find imported modules.
And most of them finished with 'not found' error, because of large
size of sys.path variable.
In future this time will be increase - setuptools adds
At 07:29 PM 2/16/2007 +0200, KoDer wrote:
2007/2/16, Phillip J. Eby [EMAIL PROTECTED]:
At 04:38 PM 2/16/2007 +0200, KoDer wrote:
.
Also, are you aware that putting a zipped version of the standard library
on sys.path already speeds up startup considerably? Python since 2.3
At 11:00 PM 2/14/2007 -0600, [EMAIL PROTECTED] wrote:
Instead, I would like to concentrate on producing a small, clean,
consistent, generator-based microthreading library. I've seen several
such libraries (including the one in PEP 342, which is fairly skeletal),
and they all work *almost* the
At 11:47 AM 2/15/2007 -0500, Jean-Paul Calderone wrote:
Is the only problem here that this style of development hasn't had been made
visible enough?
You betcha. I sure as heck wouldn't have bothered writing the module I
did, if I'd known it already existed. Or at least only written whatever
At 04:25 PM 2/15/2007 +1300, Greg Ewing wrote:
Phillip J. Eby wrote:
peak.events, for example, lets you have multiple event loops running in
the same or different threads.
Different threads is okay if you're willing to use threads,
but you might not. The reason you're using an event loop
may
At 08:41 PM 2/13/2007 +, [EMAIL PROTECTED] wrote:
and the microthreading features being discussed here are a trivial hack
somewhere in its mainloop machinery, not an entirely new subsystem that
it should be implemented in terms of.
It doesn't even require hacking the mainloop; it can be
At 08:11 AM 2/7/2007 -0200, Fabio Zadrozny wrote:
Would it be ok to add a feature request for that? I initially thought it
was completely read-only, but I find it strange that it affects the
topmost frame correctly (so, it seems that even though I get a copy, when
I alter that copy on the
At 12:06 PM 2/8/2007 +1300, Greg Ewing wrote:
That's because the topmost frame has a module's dict
as its locals, so in that case you are modifying them
directly. It's only code compiled as the body of a
function that uses an array for locals.
By topmost, he means the frame that was interrupted
At 01:17 PM 1/20/2007, Josiah Carlson wrote:
Neal Becker [EMAIL PROTECTED] wrote:
[snip]
It's not a question, it's a critique. I believe this is a misfeature since
it's so easy to make this mistake.
And it is going away with Py3k. Making it go away for Python 2.6 would
either allow for two
At 07:47 AM 1/16/2007 -0800, Guido van Rossum wrote:
On 1/16/07, James Y Knight [EMAIL PROTECTED] wrote:
On Jan 15, 2007, at 8:02 AM, Thomas Wouters wrote:
There seems to be rather a lot of confusion. No one is suggesting
Python 3.0 be anything less for the sake of backward compatibility.
At 09:50 AM 1/16/2007 -0800, Guido van Rossum wrote:
Actually it's very easy to write code using keys(), items() and
values() that works as well in 2.2 as it works in 3.0: never use the
iter* variants, and don't sweat the performance costs of creating a
list so much. If you can't afford to create
At 08:52 PM 1/16/2007 +, Steve Holden wrote:
I foresee that many people would be happy restricting their 2.X source
slightly to ensure perfect translation into (working, no necessarily
optimal) 3.0. Under those circumstances the 2to3 tool wouldn't
necessarily have to translate all valid 2.X to
At 03:18 PM 1/16/2007 -0800, Guido van Rossum wrote:
On 1/16/07, Phillip J. Eby [EMAIL PROTECTED] wrote:
The idea here being that, once 2.6 is widely-enough deployed that it can be
assumed as a base for one's users, you can simply run the translator once,
do any cleanup, and then have 3.0
At 10:23 PM 1/16/2007 +, Steve Holden wrote:
Phillip J. Eby wrote:
At 08:52 PM 1/16/2007 +, Steve Holden wrote:
I foresee that many people would be happy restricting their 2.X source
slightly to ensure perfect translation into (working, no necessarily
optimal) 3.0. Under those
At 03:47 PM 1/16/2007 -0800, Guido van Rossum wrote:
Oh, as long as we're talking adding features to 2.6 I'm fine. I
thought you were proposing changes to the plans for 3.0, as in your
proposal regarding the dict view API.
Nah, that was a side tangent, combined with a partial lack of
At 11:59 AM 1/12/2007 +, [EMAIL PROTECTED] wrote:
In order to do this, everything that has been changed in 3.0 has to have
some mechanism for working both ways in some 2.x release. I phrased this
as its feature set because I am not aware of any new functionality in
3.0 that simply isn't
At 11:10 PM 1/10/2007 +, Paul Moore wrote:
On 10/01/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I've been assuming for some time that the only hope for Py3k compatibility
within Twisted would be using PyPy as a translation layer.
Does this ring as many warning bells for me as it does
At 12:16 AM 1/6/2007 -0500, Barry Warsaw wrote:
If you've already explained it, that's fine, but if not, could you
outline what you have against epydoc?
The last I tried to work with it, it had even more hardcoded typechecking
than pydoc does, spread out over more of the code base. Also, over
At 06:35 PM 1/5/2007 -0700, Fernando Perez wrote:
Ron Adam wrote:
Laurent Gautier wrote:
From the top of my head, there might be ipython (the excellent
interactive console) is possibly using pydoc
(in any case, I would say that the authors would be interested in
developments
At 11:38 AM 12/4/2006 -0800, Mike Orr wrote:
The other approaches work fine for giving each user a private install
dir, but don't address the case of the same user wanting different
install dirs for different projects. For instance, when exploring
Pylons or TurboGears which install a lot of
At 09:49 AM 11/30/2006 -0800, Guido van Rossum wrote:
I've got a small tweak to tokenize.py that I'd like to run by folks here.
I'm working on a refactoring tool for Python 2.x-to-3.x conversion,
and my approach is to build a full parse tree with annotations that
show where the whitespace and
At 10:28 AM 11/30/2006 -0800, Guido van Rossum wrote:
Are you opposed changing tokenize? If so, why (apart from
compatibility)?
Nothing apart from compatibility. I think you should have to explicitly
request the new behavior(s), since tools (like detokenize) written to work
around the old
At 02:46 PM 11/30/2006 -0800, Mike Orr wrote:
Speaking of Virtual Python [1], I've heard some people recommending it
as a general solution to the this library breaks that other
application problem and this app needs a different version of X
library than that other app does.
It was actually
At 03:20 AM 11/30/2006 +, [EMAIL PROTECTED] wrote:
One of the things that combinator hacks is where distutils thinks it
should install to - when *I* type python setup.py install nothing tries
to insert itself into system directories (those are for Ubuntu, not me) -
~/.local is the *default*
At 06:49 PM 11/29/2006 -0500, Barry Warsaw wrote:
What might be nice would be to build a little more
infrastructure into Python to support eggs, by say adding a default
PEP 302 style importer that knows how to search for eggs in
'nests' (a directory containing a bunch of eggs).
If you have
At 05:10 AM 11/30/2006 +, [EMAIL PROTECTED] wrote:
On 04:36 am, [EMAIL PROTECTED] wrote:
easy_install uses the standard distutils configuration system, which means
that you can do e.g.
Hmm. I thought I knew quite a lot about distutils, but this particular
nugget had evaded me. Thanks!
At 01:05 PM 11/28/2006 -0800, Guido van Rossum wrote:
On 11/28/06, Barry Warsaw [EMAIL PROTECTED] wrote:
There's a related issue that may or may not be in scope for this
thread. For distros like Gentoo or Ubuntu that rely heavily on their
own system Python for the OS to work properly, I'm
At 06:41 PM 11/28/2006 -0500, Barry Warsaw wrote:
On Nov 28, 2006, at 4:19 PM, Phillip J. Eby wrote:
At 01:05 PM 11/28/2006 -0800, Guido van Rossum wrote:
On 11/28/06, Barry Warsaw [EMAIL PROTECTED] wrote:
There's a related issue that may or may not be in scope for this
thread. For distros
At 02:38 PM 11/27/2006 +0100, Jan Matejek wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Phillip J. Eby napsal(a):
Just a suggestion, but one issue that I think needs addressing is the FHS
language that leads some Linux distros to believe that they should change
Python's normal
At 07:07 PM 11/26/2006 +0200, tomer filiba wrote:
sys.maxint makes more sense there.
no, it requires *infinity* to accomplish x - y == x; y != 0, for example:
while limit 0:
limit -= len(chunk)
Um, you do realize that you're not going to be able to fit sys.maxint
strings into a list,
At 11:09 AM 11/22/2006 -0500, Ian Murdock wrote:
The first question we have to answer is: What does it mean to add
Python to the LSB? Is it enough to say that Python is present
at a certain version and above, or do we need to do more than that
(e.g., many distros ship numerous Python add-ons which
At 01:21 PM 11/26/2006 -0800, Mike Orr wrote:
A comprehensive third-party manual that integrates the documentation
would be a good place to start. Even the outline of such a manual
would be a good. That would give a common baseline of understanding
for package users, package developers, and core
At 01:56 AM 11/4/2006 +0100, Andrew Dalke wrote:
os.join assumes the base is a directory
name when used in a join: inserting '/' as needed while RFC
1808 says
The last segment of the base URL's path (anything
following the rightmost slash /, or the entire path if no
At 09:49 AM 10/25/2006 -0700, Talin wrote:
Having done a path library myself (in C++, for our code base at work),
the trickiest part is getting the Windows path manipulations right, and
fitting them into a model that allows writing of platform-agnostic code.
This is especially vexing when you
At 10:16 AM 10/25/2006 -0700, Talin wrote:
Phillip J. Eby wrote:
At 09:49 AM 10/25/2006 -0700, Talin wrote:
Having done a path library myself (in C++, for our code base at work),
the trickiest part is getting the Windows path manipulations right, and
fitting them into a model that allows
At 01:01 PM 10/2/2006 -0700, Brett Cannon wrote:
In the interest of time I have decided to go ahead and do the PEP 302
phase 2 work in C.
Just FYI, it's not possible (so far as I know) to implement phase 2 while
maintaining backward compatibility with existing 2.x code. So this work
shouldn't
At 03:48 PM 10/2/2006 -0700, Brett Cannon wrote:
On 10/2/06, Paul Moore mailto:[EMAIL PROTECTED][EMAIL PROTECTED]
wrote:
On 10/2/06, Phillip J. Eby
mailto:[EMAIL PROTECTED][EMAIL PROTECTED] wrote:
[SNIP]
I'm surprised, however, that you think working on this in C is going to be
*less* time
At 08:21 PM 10/2/2006 -0400, A.M. Kuchling wrote:
On Mon, Oct 02, 2006 at 11:27:07PM +0100, Paul Moore wrote:
Yes, I'm quite surprised at how much has appeared in pkgutil. The
what's new entry is very terse, and the module documentation itself
hasn't been updated to mention the new stuff.
At 12:58 PM 10/1/2006 -0400, Andrew Koenig wrote:
(I don't think this has been suggested yet.)
while enter_condition, exit_condition:
body
This usage makes me uneasy, not the least because I don't understand why the
comma isn't creating a tuple. That is, why whould
At 11:25 AM 9/28/2006 -0700, Brett Cannon wrote:
I will think about it, but I am still trying to get the original question
of how bad the C code is compared to rewriting import in Python from
people. =)
I would say that the C code is *delicate*, not necessarily bad. In most
ways, it's rather
At 02:11 PM 9/27/2006 -0700, Brett Cannon wrote:
But it has been suggested here that the import machinery be rewritten in
Python. Now I have never touched the import code since it has always had
the reputation of being less than friendly to work with. I am asking for
opinions from people who
At 04:11 PM 9/27/2006 -0700, Brett Cannon wrote:
On 9/27/06, Phillip J. Eby
mailto:[EMAIL PROTECTED][EMAIL PROTECTED] wrote:
At 02:11 PM 9/27/2006 -0700, Brett Cannon wrote:
But it has been suggested here that the import machinery be rewritten in
Python. Now I have never touched the import
At 05:26 PM 9/27/2006 -0700, Brett Cannon wrote:
Ah, OK. So for importing 'email', the zipimporter would call the .pyc
importer and it would ask the zipimporter, can you get me email.pyc? and
if it said no it would move on to asking the .py importer for email.py, etc.
Yes, exactly.
That's
At 12:08 AM 9/22/2006 -0700, Josiah Carlson wrote:
Phillip J. Eby [EMAIL PROTECTED] wrote:
At 08:44 PM 9/21/2006 -0700, Josiah Carlson wrote:
This can be implemented with a fairly simple package registry, contained
within a (small) SQLite database (which is conveniently shipped in
Python
At 08:10 PM 9/22/2006 +0200, Thomas Heller wrote:
Consider a package containing these files:
a/__init__.py
a/b/__init__.py
a/b/x.py
a/b/y.py
If x.py contains this:
from ..b import y
import a.b.x
from ..b import x
Python trunk and Python 2.5 both complain:
Python 2.5 (r25:51908, Sep 19 2006,
At 12:42 PM 9/22/2006 -0700, Josiah Carlson wrote:
You might as well suggest that each environment
consist of a single large zipfile containing the packages in question:
this
would actually be *more* practical (and fast!) in terms of Python startup,
and is no different from having a
At 01:54 PM 9/21/2006 -0700, Guido van Rossum wrote:
On 9/21/06, Paul Moore [EMAIL PROTECTED] wrote:
On 9/21/06, Guido van Rossum [EMAIL PROTECTED] wrote:
I think one missing feature is a mechanism whereby you can say THIS
package (gives top-level package name) lives HERE (gives filesystem
At 12:07 PM 9/22/2006 +1200, Greg Ewing wrote:
Another thought on static module namespace configuration:
It would make things a *lot* easier for py2exe, py2app
and the like that have to figure out what packages
a program depends on without running the program.
Setuptools users already explicitly
At 08:44 PM 9/21/2006 -0700, Josiah Carlson wrote:
This can be implemented with a fairly simple package registry, contained
within a (small) SQLite database (which is conveniently shipped in
Python 2.5). There can be a system-wide database that all users use as
a base, with a user-defined package
At 07:08 PM 9/18/2006 +0200, Martin Devera wrote:
So that you are right. It is not RCU. It only uses similar technique
as RCU
uses for free-ing old copy of data.
It is based on assumption that an object is typicaly used by single
thread.
Which thread owns builtins? Or module
At 04:55 PM 9/5/2006 -0400, Barry Warsaw wrote:
On Sep 5, 2006, at 4:43 PM, Jim Jewett wrote:
I think I finally figured out where Raymond is coming from.
For Raymond, head is where he started processing -- for rpartition,
this is the .endswith part.
For me, head is the start of the
At 02:08 AM 9/6/2006 +0100, David Hopwood wrote:
Barry Warsaw wrote:
The bias with these terms is clearly the English left-to-right
order. Actually, that brings up an interesting question: what would
happen if you called rpartition on a unicode string representing
Hebrew, Arabic, or other
At 05:20 PM 8/29/2006 -0700, Raymond Hettinger wrote:
* The implementation's doc string examples were not tested and don't
work (this is a deep error). One reads:
with decimal.getcontext() as ctx:
ctx.prec += 2
s = ...
return +s
To get this to work with the current
At 05:57 PM 8/29/2006 -0700, Raymond Hettinger wrote:
Phillip J. Eby wrote:
At 05:20 PM 8/29/2006 -0700, Raymond Hettinger wrote:
* The implementation's doc string examples were not tested and don't
work (this is a deep error). One reads:
with decimal.getcontext() as ctx
I rather like it, actually. I don't recall there being any real reasons to
catch a GeneratorExit exception, but even if there were, you could do the
equivalent like this:
try:
closed = True
yield 1
closed = False
finally:
if closed:
#
At 04:10 PM 8/23/2006 -0700, Guido van Rossum wrote:
IIUC this is how return currently works -- in some sense it's an
exception, but it can't be caught, and it won't escape from the
current frame. Ditto for break/continue.
The generator extensions are still very young, and I'm not against
At 01:44 AM 8/24/2006 +0200, Igor Bukanov wrote:
Regarding yield in the finally problem:
The current implementation throws RuntimeException after the yield
transfer the control back to the close method. If that is changed to
reporting a bad behavior and rethrowing GeneratorExit or its hidden
At 11:46 PM 8/15/2006 -0700, Neal Norwitz wrote:
On 8/15/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
That penalty is already paid today. Much code dealing with
ints has a type test whether it's an int or a long. If
int and long become subtypes of each other or of some abstract
type, performance
At 09:40 PM 8/11/2006 +0200, Martin v. Löwis wrote:
Michael Urman schrieb:
On 8/9/06, Michael Hudson [EMAIL PROTECTED] wrote:
The question doesn't make sense: in Python, you assign to a name,
an attribute or a subscript, and that's it.
Just to play devil's advocate here, why not to a
At 09:24 AM 8/10/2006 -0700, Guido van Rossum wrote:
On 8/10/06, James Y Knight [EMAIL PROTECTED] wrote:
It makes just as much sense as assigning to an array access, and the
semantics would be pretty similar.
No. Array references (x[i]) and attribute references (x.a) represent
locations.
At 12:28 PM 8/10/2006 -0700, Guido van Rossum wrote:
On Aug 10, 2006, at 12:31 PM, Phillip J. Eby wrote:
Honestly, it might make more sense to get rid of augmented
assignment in Py3K rather than to add this. It seems that the need
for something like this springs primarily from the existence
At 11:11 AM 8/8/2006 -0400, Jean-Paul Calderone wrote:
On Fri, 28 Jul 2006 18:00:36 -0400, Phillip J. Eby
[EMAIL PROTECTED] wrote:
At 10:55 PM 7/28/2006 +0200, Martin v. Löwis wrote:
Phillip J. Eby wrote:
The issue is that a proper fix that caches existence requires adding new
types
At 07:33 AM 7/28/2006 +0200, Martin v. Löwis wrote:
Phillip J. Eby wrote:
I'm willing to write code that makes it PEP 302 compliant, if the release
manager will bless such an addition. But if that's not acceptable, then
somebody needs to produce the necessary documentation updates or revert
At 04:07 PM 7/28/2006 -0400, Fred L. Drake, Jr. wrote:
On Friday 28 July 2006 00:49, Neal Norwitz wrote:
Based on this comment, is it really acceptable to just document a
behaviour change? ISTM there should really only be 2 choices: fix
2.5 properly or revert the change. This seemed to
At 10:55 PM 7/28/2006 +0200, Martin v. Löwis wrote:
Phillip J. Eby wrote:
The issue is that a proper fix that caches existence requires adding new
types to import.c and thus might appear to be more of a feature. I was
therefore reluctant to embark upon the work without some assurance
At 12:52 PM 7/27/2006 +0200, Georg Brandl wrote:
Armin Rigo wrote:
Hi Phillip,
On Wed, Jul 26, 2006 at 02:40:27PM -0400, Phillip J. Eby wrote:
If we don't revert it, there are two ways to fix it. One is to just
change
PEP 302 so that the behavior is unbroken by definition
At 09:49 PM 7/27/2006 -0700, Neal Norwitz wrote:
On 7/27/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
Personally, I would prefer to see it properly fixed in 2.5 rather than
having to rip it out. It's more work for me to create the proper fix than
it is to just work around it in my code
At 07:47 PM 7/26/2006 +0100, David Hopwood wrote:
Sylvain Fourmanoit wrote:
I wrote a data persistence module called miniconf, aimed at making
easy to create and safely retrieve configuration info from external,
human-readable sources using Python syntax. I feel it would eventually
make a
At 05:43 PM 7/26/2006 -0400, Sylvain Fourmanoit wrote:
The loading code could also be made a lot faster by using a dictionary
mapping AST node types to functions, instead of doing string
manipulation for each node. Each function could take 'pedantic' as a
parameter, which would eliminate
At 09:27 PM 7/23/2006 -0700, Brett Cannon wrote:
On 7/23/06, Phillip J. Eby
mailto:[EMAIL PROTECTED][EMAIL PROTECTED] wrote:
one proxy plus one namechecker equals one capability. In other words,
you could take the restricted interpreter, the proxy mechanism, and the
namechecker and leave most
At 12:50 AM 7/24/2006 -0700, Brett Cannon wrote:
OK, then I need something clarified. If you read
http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/TransitionToSecurityProxieshttp://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/TransitionToSecurityProxies
, it talks
At 12:04 PM 7/25/2006 +1200, Greg Ewing wrote:
Phillip J. Eby wrote:
When I say name checker I mean the Zope type that allows you to
specify a
list of names that are allowed for a given object. This allowing is not
based on identity or code signing or anything like that. It's just
At 01:00 PM 7/23/2006 -0700, Brett Cannon wrote:
I obviously don't want to change the feel of Python, but if I have to
remove the constructor for code objects to prevent evil bytecode or
__subclasses__() from object to prevent poking around stuff, then so be
it. For this project, security is
While investigating the need to apply http://python.org/sf/1525766 I found
that there was a modification to pkgutil during the need-for-speed sprint
that affects the PEP 302 protocol in a backwards incompatible way.
Specifically, PEP 302 documents that path_importer_cache always contains
At 12:28 PM 7/20/2006 -0700, Brett Cannon wrote:
On 7/20/06, Phillip J. Eby
mailto:[EMAIL PROTECTED][EMAIL PROTECTED] wrote:
While investigating the need to apply
http://python.org/sf/1525766http://python.org/sf/1525766 I found
that there was a modification to pkgutil during the need-for-speed
At 03:36 AM 7/11/2006 -0700, Talin wrote:
I thought a little bit more about Guido's comment that you can hide
Python objects in a C wrapper class. However, as I was trying to sleep,
I realized that you don't even need C to do it.
The trick is to store the object reference as a closure variable.
At 01:30 PM 7/11/2006 -0400, Scott Dial wrote:
Phillip J. Eby wrote:
A function's func_closure contains cell objects that hold the
variables. These are readable if you can set the func_closure of some
function of your own. If the overall plan includes the ability to
restrict
At 02:12 PM 7/11/2006 -0400, Alexander Belopolsky wrote:
On 7/11/06, Benji York [EMAIL PROTECTED] wrote:
[snip]
I'm not quite sure what you're suggesting. A guess: put the code that
isn't to be seen in the __test__ dict with a string key being the name
of the footnote?
That's right.
I
At 11:35 AM 7/11/2006 -0700, Brett Cannon wrote:
On 7/11/06, Phillip J. Eby
mailto:[EMAIL PROTECTED][EMAIL PROTECTED] wrote:
At 10:56 AM 7/11/2006 -0700, Brett Cannon wrote:
On 7/10/06, Talin
mailto:[EMAIL PROTECTED]mailto:[EMAIL PROTECTED][EMAIL PROTECTED]
wrote:
(Although, I've often
At 09:56 PM 7/6/2006 -0400, Kevin Jacobs [EMAIL PROTECTED] wrote:
Why not extend the interface to the locals builtin and add a __getitem__
that returns a proxy to access locals defined in other lexical scopes via
__{get/set/del}attr_:
def counter(num):
num = 1
def inc():
At 10:05 AM 7/6/2006 -0500, [EMAIL PROTECTED] wrote:
jan-python So.. are we only thinking about implementing this outer
jan-python scope assignment because there's lots of talk about it on
jan-python the list, ...
:-)
jan-python ... or are there actually use cases that would
At 05:17 PM 7/6/2006 -0500, Ka-Ping Yee wrote:
On Wed, 21 Jun 2006, Brett Cannon wrote:
I have been working on a design doc for restricted execution of Python
as part of my dissertation for getting Python into Firefox to replace
JavaScript on the web.
I've been doing a bunch of Firefox
At 01:00 AM 7/7/2006 +0200, Jan Kanis wrote:
On Thu, 06 Jul 2006 18:28:12 +0200, Phillip J. Eby [EMAIL PROTECTED]
wrote:
Here's the reason I think this keeps coming up, and why Guido's just
use a class argument doesn't really address the actual problem that's
taking place.
I agree this argument
At 07:04 PM 7/6/2006 -0500, Ka-Ping Yee wrote:
On Thu, 6 Jul 2006, Phillip J. Eby wrote:
As much as I'd love to have the nested scope feature, I think it's only
right to point out that the above can be rewritten as something like this
in Python 2.5:
def spam():
local_A
At 05:49 AM 7/5/2006 +0200, Guido van Rossum wrote:
* Alternate spelling of outer names when binding (e.g. .x = whatever to
bind an outer x)
We looked at and rejected globals.x = whatever. I think the same
reasoning applies here.
I thought the 'globals.x' proposal required that 'x' always be
At 10:21 AM 7/5/2006 +0200, Guido van Rossum wrote:
Thanks for bringing this up. I'm not sure what I think of it yet. One
problem I see is that there might end up being two ways to reference
variables in outer scopes: .num if you plan to assign to it, or just
num if you only reference it. I find
At 05:40 AM 7/5/2006 -0400, Scott Dial wrote:
Guido van Rossum wrote:
Would this also use ..num to refer to num in an outer scope two levels
removed?
I realize this was a wink, but it is a valid problem with the
dot-proposal.
Actually, it isn't. :) See below.
def foo(n):
def bar(n):
At 07:27 PM 7/5/2006 +0200, Guido van Rossum wrote:
However I still don't believe global has the stretchiness in its
meaning that you claim it has. Have you ever heard a Python programmer
talking about closures use the word global variable?
Are there any other native speakers who side with
At 01:24 PM 7/6/2006 +1000, Anthony Baxter wrote:
This means Google can just turn it on in sitecustomize.py and Guido
can avoid the hordes of peasants with pitchforks and burning torches.
Is that really true? It seems to me that Guido indicated a
sitecustomize-solution wasn't possible, in which
At 01:58 PM 7/2/2006 +0200, [EMAIL PROTECTED] wrote:
I believe the problem has nothing to do with how many scopes a block/function
definition has, but with what the lambda does with the scope it's given.
Currently it remembers the block and looks up the nescessary variables in it
when it's
At 07:04 PM 6/30/2006 -0400, Andrew Koenig wrote:
However, if I write
def g():
return x
x = 42
g()
the result is 42. With lexical scoping, I believe it should be undefined.
The reason is that when the compiler encounters the definition of g,
variable
At 10:13 PM 6/26/2006 -0700, Guido van Rossum wrote:
On 6/26/06, Greg Ewing [EMAIL PROTECTED] wrote:
Phillip J. Eby wrote:
It's not inconsistent - isinstance() checks __class__ in *addition* to
type() in order to allow proxying tricks like lying about your
__class__
At 09:29 AM 6/27/2006 +0200, Maric Michaud wrote:
Le mardi 27 juin 2006 05:38, Phillip J. Eby a écrit :
As it happens, this is due to the fact that E is a type, while E() is
not. There's an optimization in the isinstance() machinery that simply
checks to see if D().__class__ is a subtype
At 02:49 PM 6/27/2006 +0200, Martin v. Löwis wrote:
Phillip J. Eby wrote:
It seems that the __class__ is only accessed in some cases, but not
always, leading to what I think is a semantic inconsistency.
It's not inconsistent - isinstance() checks __class__ in *addition* to
type
At 08:08 AM 6/27/2006 -0700, Guido van Rossum wrote:
Bad idea IMO. The __name__ == __main__ rule is so ingrained, you
don't want to mess with it.
Actually, maybe we *do* want to, for this usage.
Note that until Python 2.5, it was not possible to do python -m
nested.module, so this change merely
At 12:02 PM 6/28/2006 +1200, Greg Ewing wrote:
Martin v. Löwis wrote:
Again, I believe this is all included for ExtensionClasses: it looks
for __class__ on the object if the type check fails, so that an
ExtensionClass could be actually a class derived from the C type.
Now that we have had
At 05:16 PM 6/26/2006 -0700, Martin Maly wrote:
class D(object):
... def getclass(self):
... print D.getclass
... return C
... __class__ = property(getclass)
...
isinstance(D(), D)
True
isinstance(D(), C)
D.getclass
True
isinstance in this case returns True to both C
At 01:37 PM 6/25/2006 -0700, Raymond Hettinger wrote:
No thanks. That is its own can of worms. The obvious solutions (like const
declarations, macros, or a syntax to force compile-time expression
evaluation)
are unlikely to sit well because they run afoul Python's deeply ingrained
dynamism.
At 07:04 PM 6/24/2006 +0200, Fredrik Lundh wrote:
I don't see this as much of a problem, really: we can simply restrict
the optimization to well-known data types (homogenous switches using
integers or strings should cover 99.9% of all practical cases), and then
add an opcode that checks uses a
201 - 300 of 848 matches
Mail list logo
