Mailman 3 Novembro de 2001 - Python-Dev

RE: [Python-Dev] Those import related syntax errors again...
by Samuele Pedroni 23 de Fevereiro de 2005

23 de Fevereiro de 2005

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.

18 78

What's a PyStructSequence ?
by M.-A. Lemburg 10 de Dezembro de 2001

10 de Dezembro de 2001

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/

9 31

-DINET6 in Makefile
by M.-A. Lemburg 3 de Dezembro de 2001

3 de Dezembro de 2001

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/

2 6

gc.garbage
by Tim Peters 1 de Dezembro de 2001

1 de Dezembro de 2001

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?

5 8

Re: problems with DBM nonuniformity
by Skip Montanaro 30 de Novembro de 2001

30 de Novembro de 2001

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/)

2 1

ArtifactFile: I can't change my patch files
by James C. Ahlstrom 30 de Novembro de 2001

30 de Novembro de 2001

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

1 0

[development doc updates]
by Fred L. Drake 30 de Novembro de 2001

30 de Novembro de 2001

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.)

1 0

Re: _PyTuple_Resize() in 2.2
by Gustavo Niemeyer 29 de Novembro de 2001

29 de Novembro de 2001

> >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 ]

4 4

__metaclass__
by Thomas Heller 29 de Novembro de 2001

29 de Novembro de 2001

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

2 1

[development doc updates]
by Fred L. Drake 29 de Novembro de 2001

29 de Novembro de 2001

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.

1 0