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.
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
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 +--------------------------------------+
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
> 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
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/
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
"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
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-...
)
John
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.
