Hi.
[Mark Hammond]
> The point isn't about my suffering as such. The point is more that
> python-dev owns a tiny amount of the code out there, and I don't believe we
> should put Python's users through this.
>
> Sure - I would be happy to "upgrade" all the win32all code, no problem. I
> am also happy to live in the bleeding edge and take some pain that will
> cause.
>
> The issue is simply the user base, and giving Python a reputation of not
> being able to painlessly upgrade even dot revisions.
I agree with all this.
[As I imagined explicit syntax did not catch up and would require
lot of discussions.]
[GvR]
> > Another way is to use special rules
> > (similar to those for class defs), e.g. having
> >
> > <frag>
> > y=3
> > def f():
> > exec "y=2"
> > def g():
> > return y
> > return g()
> >
> > print f()
> > </frag>
> >
> > # print 3.
> >
> > Is that confusing for users? maybe they will more naturally expect 2
> > as outcome (given nested scopes).
>
> This seems the best compromise to me. It will lead to the least
> broken code, because this is the behavior that we had before nested
> scopes! It is also quite easy to implement given the current
> implementation, I believe.
>
> Maybe we could introduce a warning rather than an error for this
> situation though, because even if this behavior is clearly documented,
> it will still be confusing to some, so it is better if we outlaw it in
> some future version.
>
Yes this can be easy to implement but more confusing situations can arise:
<frag>
y=3
def f():
y=9
exec "y=2"
def g():
return y
return y,g()
print f()
</frag>
What should this print? the situation leads not to a canonical solution
as class def scopes.
or
<frag>
def f():
from foo import *
def g():
return y
return g()
print f()
</frag>
[Mark Hammond]
> > This probably won't be a very popular suggestion, but how about pulling
> > nested scopes (I assume they are at the root of the problem)
> > until this can be solved cleanly?
>
> Agreed. While I think nested scopes are kinda cool, I have lived without
> them, and really without missing them, for years. At the moment the cure
> appears worse then the symptoms in at least a few cases. If nothing else,
> it compromises the elegant simplicity of Python that drew me here in the
> first place!
>
> Assuming that people really _do_ want this feature, IMO the bar should be
> raised so there are _zero_ backward compatibility issues.
I don't say anything about pulling nested scopes (I don't think my opinion
can change things in this respect)
but I should insist that without explicit syntax IMO raising the bar
has a too high impl cost (both performance and complexity) or creates
confusion.
[Andrew Kuchling]
> >Assuming that people really _do_ want this feature, IMO the bar should be
> >raised so there are _zero_ backward compatibility issues.
>
> Even at the cost of additional implementation complexity? At the cost
> of having to learn "scopes are nested, unless you do these two things
> in which case they're not"?
>
> Let's not waffle. If nested scopes are worth doing, they're worth
> breaking code. Either leave exec and from..import illegal, or back
> out nested scopes, or think of some better solution, but let's not
> introduce complicated backward compatibility hacks.
IMO breaking code would be ok if we issue warnings today and implement
nested scopes issuing errors tomorrow. But this is simply a statement
about principles and raised impression.
IMO import * in an inner scope should end up being an error,
not sure about 'exec's.
We will need a final BDFL statement.
regards, Samuele Pedroni.
A bug report on SF made me aware of an apprently new type in Python
called PyStructSequence. There are no docs on the type (at least
not in the usual places).
Is it official yet ?
--
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company: http://www.egenix.com/
Python Software: http://www.lemburg.com/python/
What's the reasoning behind putting -DINET6 into the default
compiler options of the generic Makefile ?
I'm just asking because such a define will be inherited by
all extensions being compiled with distutils and the Makefile.pre.in
setup process... sounds like trouble if you ask me.
Shouldn't the define be placed into the pyconfig.h file or
only in those extensions which need it ?
--
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company: http://www.egenix.com/
Python Software: http://www.lemburg.com/python/
I notice the gc docs say:
The following variable is provided for read-only access:
^^^^^^^^^^^^^^^^
garbage
A list of objects which the collector found to be unreachable ...
This isn't clear to me. When I find finalizer cycles in gc.trash, I want to
clean them up by breaking the cycles. Unless I remove the instances from
gc.trash too, their appearance in that list keeps them alive despite that
the cycles are broken. But "read-only access" seems to imply "don't
mutate", and I don't believe that was intended. True? False?
Jason> On Linux, "whitelist.db" = whitelist.db when the default module is
Jason> dbhash, so there is no problem:
...
Jason> However on Solaris for example (default module of dbm):
Jason> % python -c "import anydbm;wl = anydbm.open('whitelist.db','c')"
Jason> % ls -l whitelist*
Jason> -rw------- 1 jason users 0 Nov 29 19:13 whitelist.db.dir
Jason> -rw------- 1 jason users 0 Nov 29 19:13 whitelist.db.pag
Jason> Under Linux, the dbm module acts differently, adding a '.db'
Jason> suffix to the given filename:
Jason> % python -c "import dbm;wl = dbm.open('whitelist.db','c')"
Jason> % ls -l whitelist*
Jason> -rw------- 1 jasonrm acl 16384 Nov 29 17:21 whitelist.db.db
Jason> So, I can't rely on comparing "whitelist" with "whitelist.db"
Jason> filename to filename since the latter might not exist.
...
Jason> Does anyone have some suggestions on how I might support this
Jason> feature in a cross-platform, and generic fashion?
Seems to me the natural thing to do would be to add "get_data_filename" and
"get_index_filename" methods (or something similar) to the underlying
modules (dbhash, bsddb, dbm, etc) and expose them through anydbm.
It's too late for 2.2, but I suspect if you implemented something and method
name(s) could be settled on it would make it into CVS early in the 2.3
cycle. This seems like a small enough change that you just file a bug
report on SourceForge with the proposal and add an implementation when you
have something workable.
--
Skip Montanaro (skip(a)pobox.com - http://www.mojam.com/)
I am trying to replace files in my patch #483466, but
I am getting
File delete: ArtifactFile: Permission Denied
on SourceForge. If I need to be a member of the Python
project to do this, could someone please add me? Or
tell me what's wrong?
The new files implement the changes to sys.path[0]
that we have been discussing. I still need to make
further changes to import.c so that "" and relative
paths are handled. So don't install this patch yet,
but look it over for problems if you want.
Jim
The development version of the documentation has been updated:
http://python.sourceforge.net/devel-docs/
Updated the httplib docs to cover the API provided in recent versions of
Python. Please review and comment on this and all other new material!
(In case you have forgetten, other large chunks of new material include the
sections covering modules in the email package, the compiler package, and
the Tkinter/Tix chapter.)
> >You may want to include in your Python 2.2 change log the fact
> >that _PyTuple_Resize() has now 2 arguments instead of 3. The last
>
> Good suggestion; I've added it to the CVS version. Thanks!
One more: readline() method (and probably others) now raise an
exception if called for a directory. It used to return an empty
string. I haven't found this in Python's sourceforge changelog either.
--
Gustavo Niemeyer
[ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ]
Maybe I'm missing something, but why doesn't the following
raise errors:
class X(object):
__metaclass__ = type
X()
X(1)
X(1, 2, 3, a="x", b="y")
I would have expected 'this constructor takes no arguments'
errors on the last two lines. Or is this expected behaviour?
Thomas
The development version of the documentation has been updated:
http://python.sourceforge.net/devel-docs/
Added section of example regular expressions to the "re" module docs.
Various small clarifications.
