Python-Dev May 2004

python-dev@python.org

86 participants
125 discussions

RE: [Python-Dev] Those import related syntax errors again...

by Samuele Pedroni

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.

16 years, 1 month

New Subscriber

by Dave Hastings

Hello fellow developers. My name is David Hastings and I am a new subscriber to the python-dev list. I'm also a little new to python but I can get around in it. I have been learning how to use the language for about a year now. First, some information about myself. I am a senior attending the University of Minnesota. Today was the last day of classes for the spring semester and also the last day of my college career. I am receiving a Bachelor of Science in Computer Science degree. Man it feels good to be done ! This last semester a friend (Michael Sampson) and I took an independent study class where we sign up with a Professor and decide on a project and work on it until the end of the semester. The project that was decided upon, with the advice of the Professor, was to make a CGIpm python module that reflected CGI.pm for perl. We noticed that there is a current cgi module for python and even a cgipm module. These modules are very useful, but did not include all the functions that CGI.pm for perl provides. It turns out that my Professor really likes python and would have loved to see a CGIpm python module for python that was like the CGI.pm module for perl. (I think he is a bit turned off by perl, more because it is a language that is not that easy to pick up unless you are familiar with unix, namely sed and awk.) We decided to take the oportunity and wrote CGIpm.py. I'm not going to go into a lot of details in this e-mail since it is an introductory e-mail, but the first version of CGIpm.py is complete. I feel that this e-mail is a bit long winded as is, so I think I will end it. I can not wait to start reading about all the new ideas, development, and contributions that this list will provide. Dave

16 years, 8 months

Can we please have a better dict interpolation syntax?

by Greg Ewing

I have just had the experience of writing a bunch of expressions of the form "create index %(table)s_lid1_idx on %(table)s(%(lid1)s)" % params and found myself getting quite confused by all the parentheses and "s" suffixes. I would *really* like to be able to write this as "create index %{table}_lid1_idx on %{table}(%{lid1})" % params which I find to be much easier on the eyes. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg(a)cosc.canterbury.ac.nz +--------------------------------------+

16 years, 9 months

PEP 292 - simpler string substitutions

by Barry Warsaw

PEP 292 describes simpler string substitutions, i.e. $-strings. PEP 320 says that this is going into Python 2.4. I've had some code laying around that implemented $-strings as a subclass of unicode instead of what PEP 292 describes as a new string method. The advantage to this approach is that the feature is provided with no language changes, or changes to the existing string classes. I've cleaned up my code and posted a patch to SF. I've also checked in an updated PEP 292 that fits my implementation more closely. Please review the PEP and the patch: http://www.python.org/peps/pep-0292.html The reference implementation in the patch adds a couple of extra things that aren't part of the PEP, but were discussed at Monday's sprint. Specifically: - a top level package called 'stringlib' is added to the standard library. - the dstring class implemented PEP 292 is available through stringlib.dstring - some handy dict subclasses that work with the dstring class are also provided. The idea was that some of the constants and functions we want to keep from the string module would go in the stringlib package. That's not essential to the PEP of course. If this stuff is approved for Python 2.4, I'll add test cases and documentation. -Barry

16 years, 9 months

Re: [Python-Dev] Python startup time: String objects

by Martin v. L�wis

> Even with cPickle? AFAIR: Yes. It was not orders of magnitude slower anymore, but significantly slower. > I'm still worried about your patch, because it changes all uses of > marchal, not just how code objects are marshalled. The marshal module > *is* used by other apps... The change is backwards-compatible in the sense that existing files can be unmarshalled just fine. Problems will only arise if new marshal output is unmarshalled by old versions, which could be solved with an option during marshalling. Regards, Martin

16 years, 9 months

Stackless Python

by Eyal Lotem

Stackless Python and its tasklets would be great! Why is Python still not stackless? __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/

16 years, 10 months

LC_NUMERIC, gtk and Patch 774665

by Nick Coghlan

A problem was recently reported on wxPython-dev that smells strongly of this issue with GTK changing the LC_NUMERIC locale to something other than 'C' causing subsequent severe problems in the handling of floats by the Python interpreter. I went looking for Christian's proposed PEP (to make Python more locale agnostic when it comes to LC_NUMERIC), and didn't find it listed in PEP 0. The last activity on Gustavo's patch was in December 2003, and the last comment in September. What's the current state of this? Regards, Nick. -- Nick Coghlan | Brisbane, Australia Email: ncoghlan(a)email.com | Mobile: +61 409 573 268

16 years, 10 months

RE: [Python-Dev] Why aren't more things weak referencable

by Robert Brewer

"Martin v. Löwis" wrote: > Raymond Hettinger wrote: > > Instances of classes inheriting from str, tuple, etc cannot > be weakly > > referenced. Does anyone know the reason for this? > > In addition to the reason Christian gave, one (conceptually more > important) reason is that strings can't participate in cycles. Weak > references were introduced as a mechanism to avoid creating cyclic > structures, so that "backward" links could be made weak references. > > It appears that people have then been eager to add weakref support > to other datatypes. IMO, they have been too eager. For example, I > can't see a reason why Unicode objects should be weakly referencable > (just as I can't see a reason for plain strings). Never rule out "foolish" consistencies. I can imagine a system where multiple, heterogeneous values all get run through a weakref processor; to have string objects pass through without Yet Another try/except would be a design and maintenance boon. Quite similar to my current "pet peeve": >>> None > 3 False >>> None > 'hoopy' False >>> None > True False >>> None > datetime.date(2004, 5, 31) Traceback (most recent call last): File "<interactive input>", line 1, in ? TypeError: can't compare datetime.date to NoneType ...writing an O-R mapper, this particular hobgoblin bites me rather often ;) Robert Brewer MIS Amor Ministries fumanchu(a)amor.org

16 years, 10 months

Contribution Licensing Agreement?

by John J Lee

I remember from a year or so ago that the various PSF licensing agreements were not finalised, but Guido said contributors should still sign them in their draft form. Have things moved on at all since then? I recall that Guido said legal ditherings had been going on for a year or so even back then. cookielib is a derived work of libwww-perl, so I guess I need to get Gisle Aas (libwww-perl's author) to sign something if it is to be part of 2.4, right? http://www.python.org/psf/psf-contributor-agreement.html (BTW, I've written LaTeX docs for cookielib now, comments welcome. Patch coming soon... http://codespeak.net/svn/user/jjlee/wwwsearch/ClientCookie/branch/python-2.… ) John

16 years, 10 months

pre-announce: Python 2.4a1 is about a month away

by Anthony Baxter

This is a pre-announcement that the first alpha of Python 2.4 is about a month away. The purpose of this notice is to give people a heads up - if you have a bug that you want to see fixed for 2.4, start looking at it now. Fixes are welcome through the release cycle, although after the first beta fixes that result in a change to behaviour will be much less likely to be accepted. So, if you have a bug you want to see fixed, what should you do? - If it's not logged on SF, log it. - If it's logged, consider adding a patch that fixes the problem, or at least a simple test case that demonstrates the bug. - If someone else has supplied a fix, see if this fix works for you, and post your results to the bug. - If there's a working fix, feel free to add a note asking for the fix to go into CVS. The SF bug tracker for Python has a _lot_ of bugs in it, and it's easy for bugs to be overlooked. If you're just interested in what's coming up in 2.4, see the current development version of the "What's New in 2.4" document at http://www.python.org/dev/doc/devel/whatsnew/whatsnew24.html On behalf of the python-dev team, thanks! Anthony [This form of pre-announcement will hopefully become a part of the release process for all future releases of Python, both major and bugfix releases, to give people a chance to get their bugfix-of-choice submitted in time. Any feedback on this process, please feel free to email me] -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

16 years, 10 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev May 2004