Re: [Python-Dev] [Python-checkins] python/dist/src/Lib urllib.py, 1.169, 1.170
Am Samstag, 10. September 2005 04:27 schrieb [EMAIL PROTECTED]:
> Update of /cvsroot/python/python/dist/src/Lib
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv3622
>
> Modified Files:
> urllib.py
> Log Message:
> Simplify and speed-up quote_plus().
>
> Index: urllib.py
> ===
> RCS file: /cvsroot/python/python/dist/src/Lib/urllib.py,v
> retrieving revision 1.169
> retrieving revision 1.170
> diff -u -d -r1.169 -r1.170
> --- urllib.py 9 Sep 2005 22:27:13 - 1.169
> +++ urllib.py 10 Sep 2005 02:27:41 - 1.170
> @@ -1115,12 +1115,9 @@
> def quote_plus(s, safe = ''):
> """Quote the query fragment of a URL; replacing ' ' with '+'"""
> if ' ' in s:
> -l = s.split(' ')
> -for i in range(len(l)):
> -l[i] = quote(l[i], safe)
> -return '+'.join(l)
> -else:
> -return quote(s, safe)
> +s = s.replace(' ', '+')
> +safe += '+'
> +return quote(s, safe)
>
> def urlencode(query,doseq=0):
> """Encode a sequence of two-element tuples or dictionary into a URL
> query string.
You also change the behaviour. Before:
>>> urllib.quote_plus("alpha+beta gamma")
'alpha%2Bbeta+gamma'
After:
>>> urllib.quote_plus("alpha+beta gamma")
'alpha+beta+gamma'
Is that intentional? If so, you also have to update the documentation, which
currently reads:
quote_plus(string[, safe])
... Plus signs in the original string are escaped unless they are included in
safe. ...
Peter
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Wanting to learn
Hi My name is Jason & i have a great interest in progamming whether it be python or what have you. From my understanding Python is written in C right ? I am willing to do grunt work just to learn .I a quick to catch on given the right path to follow.Please let me know if you will let me learn help in my endeavor to learn to program. I am eager to hear back .Thanks for your time.Or if not Maybe you could point me in the right direction Jason ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3000 and new style classes
On 9/9/05, holger krekel <[EMAIL PROTECTED]> wrote: > > > > It matters because "metaclass = type" is completely obscure. How would > > any non-expert have a clue what it means? > > How would this non-expert have a clue what > "from __future__ import new_style_classes" means? > That is the point!!! If I am a developer, I think is better to have a __future__ statement for things that are planned to change in the future. If you are a non-expert, you will google for new style classes, and I think is far easier to understand what a new style class is than metaclasses. How many non-expert knows about nested scopes subjects introduced in Py2.1? it has a __future__ statement. Additionaly, a __future__ statement can be easily removed when a new Python release cames. We could simply use the script Tools/scripts/cleanfuture.py to eliminate those __future__ imports when Py3.0 is available. The same applies for generators in Py2.4 ... -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3000 and new style classes
On 9/9/05, Michael Chermside <[EMAIL PROTECTED]> wrote: > I think it would > provide a REALLY nice migration path if it were possible to write > Python 3.0 code in Python 2.x (for large values of x) so long as you > included an appropriate preamble of "from __future__ import" statements. Perhaps I was not clear, but that was the reason of my proposal. I agree it is not necesary, but this will help developers to transition from Py2.X to Py3.0 in a consistent way. I will vote +1 for any attemps to populate __future__ module if that enables writing working Py3K code as soon as possible in Py2.X .. > I love making Perl users jealous, So I love! ;) -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] unintentional and unsafe use of realpath()
Hi,
In Python 2.4.1, Python/sysmodule.c includes a function PySys_SetArgv().
One of the things it does is attempt to resolve symbolic links into
absolute paths. Currently, it uses readlink() if configure found that
your system supports it, and then it tries to do the same thing again
using realpath() if you system supports that.
This seems wrong; there's really no reason to do both. So here's a
patch to move the realpath() usage into a #else following the
HAVE_READLINK test:
--- Python-2.4.1/Python/sysmodule.c.readlink2005-09-10 14:05:26.0
-0400
+++ Python-2.4.1/Python/sysmodule.c 2005-09-10 14:06:00.0 -0400
@@ -1211,7 +1211,7 @@
}
}
}
-#endif /* HAVE_READLINK */
+#else /* HAVE_READLINK */
#if SEP == '\\' /* Special case for MS filename syntax */
if (argc > 0 && argv0 != NULL) {
char *q;
@@ -1244,6 +1244,7 @@
#endif
p = strrchr(argv0, SEP);
}
+#endif /* HAVE_READLINK */
if (p != NULL) {
#ifndef RISCOS
n = p + 1 - argv0;
Another problem (which I have not fixed) is that when realpath() is
used, in some cases MAXPATHLEN is smaller than the system's
PATH_MAX/pathconf(path, _PC_PATH_MAX). When that happens, the
realpath() usage is a potential buffer overflow, which can be
selectively aggravated using a carefully constructed symbolic link.
This is the case currently on Fedora Core (Linux) at least, and possibly
other OSes.
Recent versions of gcc include a feature to check for this kind of bug
at runtime, and if you build python with gcc+glibc and the gcc command
line arguments "-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector"
it will give you a failure that looks something like:
case $MAKEFLAGS in \
*-s*) LD_LIBRARY_PATH=/home/pjones/build/BUILD/Python-2.4.1: CC='gcc
-pthread' LDSHARED='gcc -pthread -shared' OPT='-O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=pentium4
-fasynchronous-unwind-tables -D_GNU_SOURCE -fPIC -I/usr/kerberos/include
' ./python -E ./setup.py -q build;; \
*) LD_LIBRARY_PATH=/home/pjones/build/BUILD/Python-2.4.1: CC='gcc
-pthread' LDSHARED='gcc -pthread -shared' OPT='-O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=pentium4
-fasynchronous-unwind-tables -D_GNU_SOURCE -fPIC -I/usr/kerberos/include
' ./python -E ./setup.py build;; \
esac
*** buffer overflow detected ***: ./python terminated
=== Backtrace: =
/lib/libc.so.6(__chk_fail+0x41)[0x590495]
/lib/libc.so.6(__ptsname_r_chk+0x0)[0x590ac0]
/home/pjones/build/BUILD/Python-2.4.1/libpython2.4.so.1.0(PySys_SetArgv
+0x1a1)[0x228cf5]
/home/pjones/build/BUILD/Python-2.4.1/libpython2.4.so.1.0(Py_Main
+0x671)[0x22bedd]
./python(main+0x2a)[0x804859a]
/lib/libc.so.6(__libc_start_main+0xdf)[0x4c74ff]
./python[0x80484ed]
=== Memory map:
00185000-0026e000 r-xp 03:03
278531 /home/pjones/build/BUILD/Python-2.4.1/libpython2.4.so.1.0
0026e000-00295000 rwxp 000e8000 03:03
278531 /home/pjones/build/BUILD/Python-2.4.1/libpython2.4.so.1.0
00295000-00298000 rwxp 00295000 00:00 0
00495000-004ae000 r-xp 03:03 1966150/lib/ld-2.3.90.so
004ae000-004af000 r-xp 00018000 03:03 1966150/lib/ld-2.3.90.so
004af000-004b rwxp 00019000 03:03 1966150/lib/ld-2.3.90.so
004b2000-005d7000 r-xp 03:03 1966261/lib/libc-2.3.90.so
005d7000-005d9000 r-xp 00124000 03:03 1966261/lib/libc-2.3.90.so
005d9000-005db000 rwxp 00126000 03:03 1966261/lib/libc-2.3.90.so
005db000-005dd000 rwxp 005db000 00:00 0
005df000-00602000 r-xp 03:03 1966272/lib/libm-2.3.90.so
00602000-00603000 r-xp 00022000 03:03 1966272/lib/libm-2.3.90.so
00603000-00604000 rwxp 00023000 03:03 1966272/lib/libm-2.3.90.so
00606000-00608000 r-xp 03:03 1966270/lib/libdl-2.3.90.so
00608000-00609000 r-xp 1000 03:03 1966270/lib/libdl-2.3.90.so
00609000-0060a000 rwxp 2000 03:03 1966270/lib/libdl-2.3.90.so
006f7000-00705000 r-xp 03:03
1966283/lib/libpthread-2.3.90.so
00705000-00706000 r-xp d000 03:03
1966283/lib/libpthread-2.3.90.so
00706000-00707000 rwxp e000 03:03
1966283/lib/libpthread-2.3.90.so
00707000-00709000 rwxp 00707000 00:00 0
0073f000-00743000 r-xp 03:03
1442230/home/pjones/build/BUILD/Python-2.4.1/Modules/stropmodule.so
00743000-00745000 rwxp 4000 03:03
1442230/home/pjones/build/BUILD/Python-2.4.1/Modules/stropmodule.so
00a22000-00a2b000 r-xp 03:03
1966127/lib/libgcc_s-4.0.1-20050906.so.1
00a2b000-00a2c000 rwxp 9000 03:03
1966127/lib/libgcc_s-4.0.1-20050906.so.1
00df7000-00df9000 r-xp 03:03 1968751/lib/libutil-2.3.90.so
00df9000-00dfa000 r-xp 1000 03:03 1968751/lib/libutil-2.3.90.so
00dfa000-00dfb000 rwxp 2000 03
Re: [Python-Dev] PEP 3000 and iterators
On 9/9/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > For the builtins, it would actually be possible to do this by simply > importing an alternate builtins module. Something like > > from future_builtins import min, max, zip, range > Yes. A straightforward solution... > For methods on standard objects like dicts it's not really possible > either way; the type of a dict is determined by the module containing > the code creating it, not the module containing the code using it. > I had that in mind when I wrote my post; changing types is not the way, that will not work. That is why I proposed __future__ (I really do not know very well the implementation details of that feature) because I think the parser/compiler can (magically) make the replacements, e.g. dict.items -> dict.iteritems for Py2.X series in codes *using* dicts . Do you think something like this could be implemented in a safer way? -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Wanting to learn
Jason, this mailing list is related to Python development. If you are a new at Python, a far better place for help is comp.lang.python group. Please go to Google Grups and take a look. If you do a search in those archives, you will find many good links. -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] First release of Shed Skin, a Python-to-C++ compiler.
After nine months of hard work, I am proud to introduce my baby to the
world: an experimental Python-to-C++ compiler. It can convert many
Python programs into optimized C++ code, without any user intervention
such as adding type declarations. It uses rather advanced static type
inference techniques to deduce type information by itself. In
addition, it determines whether deduced types may be parameterized,
and if so, it generates corresponding C++ generics. Based on deduced
type information, it also attempts to convert heap allocation into
stack and static preallocation (falling back to libgc in case this
fails.)
The compiler was motivated by the belief that in many cases it should
be possible to automatically deduce C++ versions of Python programs,
enabling users to enjoy both the productivity of Python and the
efficiency of C++. It works best for Python programs written in a
relatively static C++-style, in essence enabling users to specify C++
programs at a higher level.
At the moment the compiler correctly handles 124 unit tests, six of
which are serious programs of between 100 and 200 lines:
-an othello player
-two satisfiability solvers
-a japanese puzzle solver
-a sudoku solver
-a neural network simulator
Unfortunately I am just a single person, and much work remains to be
done. At the moment, there are several limitations to the type of
Python programs that the compiler accepts. Even so, there is enough of
Python left to be able to remain highly productive in many cases.
However, for most larger programs, there are probably some minor
problems that need to be fixed first, and some external dependencies
to be implemented/bridged in C++.
With this initial release, I hope to attract other people to help me
locate remaining problems, help implement external dependencies, and
in the end hopefully even to contribute to the compiler itself. I
would be very happy to receive small programs that the compiler does
or should be able to handle. If you are a C++ template wizard, and you
would be interested in working on the C++ implementation of builtin
types, I would also love to get in contact with you. Actually, I'd
like to talk to anyone even slightly interested in the compiler, as
this would be highly motivating to me.
The source code is available at the following site. Please check the
README for simple installation/usage instructions. Let me know if you
would like to create ebuild/debian packages.
Sourceforge site: http://shedskin.sourceforge.net
Shed Skin blog: http://shed-skin.blogspot.com
Should you reply to this mail, please also reply to me directly. Thanks!
Credits
Parts of the compiler have been sponsored by Google, via its Summer of
Code program. I am very grateful to them for keeping me motivated
during a difficult period. I am also grateful to the Python Software
Foundation for chosing my project for the Summer of Code. Finally, I
would like to thank my university advisor Koen Langendoen for guiding
this project.
Details
The following describes in a bit more detail various aspects of the
compiler. Before seriously using the compiler, please make sure to
understand especially its limitations.
Main Features
-very precise, efficient static type inference (iterative object
contour splitting, where each iteration performs the cartesian product
algorithm)
-stack and static pre-allocation (libgc is used as a fall-back)
-support for list comprehensions, tuple assignments, anonymous funcs
-generation of arbitrarily complex class and function templates
(even member templates, or generic, nested list comprehensions)
-binary tuples are internally analyzed
-some understanding of inheritance (e.g. list(dict/list) becomes
list>)
-hierarchical project support: generation of corresponding C++
hierarchy, including (nested) Makefiles; C++ namespaces
-annotation of source code with deduced types
-builtin classes, functions (enumerate, sum, min, max, range, zip..)
-polymorphic inline caches or virtual vars/calls (not well tested)
-always unbox scalars (compiler bails out with error if scalars are
mixed with pointer types)
-full source code available under the MIT license
Main Limitations/TODO's
-Windows support (I don't have Windows, sorry)
-reflection (getattr, hasattr), dynamic inheritance, eval, ..
-mixing scalars with pointer types (e.g. int and None in a single variable)
-mixing unrelated types in single container instance variable other
than tuple-2
-holding different types of objects in tuples with length >2;
builtin 'zip' can only take 2 arguments.
-exceptions, generators, nested functions, operator overloading
-recursive types (e.g. a = []; a.append(a))
-expect some problems when mixing floats and ints together
-varargs (*x) are not very well supported; keyword args are not supported yet
-arbitrary-size arithmetic
-possible non-termination ('recursive customization', have not
encountered it yet)
-profiling will be required for sca
[Python-Dev] IDLE development
Hello, More than a year and a half ago, I posted a big patch to IDLE which adds support for completion and much better calltips, along with some other improvements. Since then, I had some mail conversations with Kurt B. Kaiser, who is responsible for IDLE, which resulted in nothing. My last mail, from Jul 10, saying (with more details) "I made the minor changes you asked for, let's get it in, it's not very complicated" was unanswered. This is just an example of the fact that IDLE development was virtually nonexistent in the last months, because most patches were simply ignored. I and my colleges use IDLE intensively - that is, a heavily patched IDLE. It includes my patch and many other improvements made by me and my friends. The improved IDLE is MUCH better than the standard IDLE, especially for interactive work. Since we would like to share our work with the rest of the world, if nothing is changed we would start a new IDLE fork soon, perhaps at python-hosting.com. I really don't like that - maintaining a fork requires a lot of extra work, and it is certain that many more people will enjoy our work if it integrated in the standard Python distribution. But sending patches and watching them stay open despite a continuous nagging is worse. Please, either convince KBK to invest more time in IDLE development, or find someone else who would take care of it. If you like, I would happily help in the development. I hope I am not sounding offensive. It's actually quite simple: if the excellent development environment IDLE can't develop inside standard Python, it should be developed outside it. As I said, I prefer the first option. Have a good week, Noam Raphael ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] IDLE development
On 9/10/05, Noam Raphael <[EMAIL PROTECTED]> wrote: > I and my colleges use IDLE intensively - that is, a heavily patched > IDLE. It includes my patch and many other improvements made by me and > my friends. > > The improved IDLE is MUCH better than the standard IDLE, especially > for interactive work. Could it be that this is a rather subjective judgement? It wouldn't be the first time that someone pushing for their personal set of functionality changes is overlooking the needs of other user groups. > Since we would like to share our work with the > rest of the world, if nothing is changed we would start a new IDLE > fork soon, perhaps at python-hosting.com. I have no problem with this. You might be able to save yourself some maintenance work by structuring your version as a set of subclasses rather than a set of patches (even if you distribute it as a complete working program). Many people have needs that aren't met by standard Python; they write their own modules or extensions and distribute these independently from Python; your case probably isn't all that different. Often the needs of certain user groups and the development speeds of such 3rd party modules are so different that it simply doesn't make sense to fold them in the Python distribution anyway -- consider what you would have to do if Kurt accepted your patches: you'll still have to wait until Python 2.5 is released before others can benefit from your changes, and if you come up with an improvement after that release, your next chance will be 18 months later... -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3000 and iterators
On 9/10/05, Lisandro Dalcin <[EMAIL PROTECTED]> wrote: > On 9/9/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > For methods on standard objects like dicts it's not really possible > > either way; the type of a dict is determined by the module containing > > the code creating it, not the module containing the code using it. > > I had that in mind when I wrote my post; changing types is not the > way, that will not work. That is why I proposed __future__ (I really > do not know very well the implementation details of that feature) > because I think the parser/compiler can (magically) make the > replacements, e.g. dict.items -> dict.iteritems for Py2.X series in > codes *using* dicts . Do you think something like this could be > implemented in a safer way? Please trust me. It can't be made to work. The compiler doesn't know the types of the variables so it doesn't know whether in a particular occurrence of the expression 'x.items", x is a dict or not. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] IDLE development
Guido van Rossum wrote: > Often the needs of certain user groups and the development speeds of > such 3rd party modules are so different that it simply doesn't make > sense to fold them in the Python distribution anyway -- consider what > you would have to do if Kurt accepted your patches: you'll still have > to wait until Python 2.5 is released before others can benefit from > your changes, and if you come up with an improvement after that > release, your next chance will be 18 months later... Isn't separate distribution the way the *current* version of Idle was developed? I seem to recall it existing as IDLEFork for a long time so that it could have a more rapid release cycle before being rolled into the main distribution. This approach also allows a wider audience to asess the subjective benefits of any changes made - many more people will download and try out a separate IDE than will download and try out a patch to the main distribution. I'm such a one, even though I believe my main problems with Idle lie in the Tcl/tk toolkit (so I don't expect any application level changes to alter my opinion much). Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python code.interact() and UTF-8 locale
Hi,
I found a bug in Python interactive command line (program python alone:
looks to be code.interact() function in code.py). With UTF-8 locale, the
command << u"é" >> returns << u'\xc3\xa9' >> and not << u'\xE9' >>.
Remember: the french e with acute is Unicode 233 (0xE9), encoded \xC3
\xA9 in UTF-8.
Another example of the bug:
#-*- coding: UTF-8 -*-
code = "u\"%s\"" % "\xc3\xa9"
compiled = compile(code,'',"single")
exec compiled
Result :
u'\xc3\xa9'
Excepted result :
u'\xe9'
After long hours of debuging (read Python documentation, debug Python
with gdb, read Python C source code, ...) I found the origin of the bug:
function parsestr() in Python/compile.c. This function translate a
string to a unicode string (or a classic string). The problem is when
the encoding declaration doesn't exist: the string isn't converted.
Solution to the first code:
#-*- coding: ascii -*-
code = """#-*- coding: UTF-8 -*-
u\"%s\ % "\xc3\xa9"
compiled = compile(code,'',"single")
exec compiled
Proposition: u"..." and unicode("...") should use sys.stdin.encoding by
default. They will work as unicode("...", sys.stdin.encoding). Or
easier, the compiler should use sys.stdin.encoding and not ascii as
default encoding.
Sorry if someone already reported this bug. And, is it a bug or a
feature ? ;-)
Bye, Haypo (who just have subscribed to the mailing list)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3000 and iterators
On Sep 10, 2005, at 6:07 PM, Lisandro Dalcin wrote: > I had that in mind when I wrote my post; changing types is not the > way, that will not work. That is why I proposed __future__ (I really > do not know very well the implementation details of that feature) > because I think the parser/compiler can (magically) make the > replacements, e.g. dict.items -> dict.iteritems for Py2.X series in > codes *using* dicts . Do you think something like this could be > implemented in a safer way? > No, that cannot work. However, there is a very obvious and trivial solution. Do not remove dict.iteritems in Py 3.0. Py2.X programs wishing forward compat can avoid dict.items and use instead dict.iteritems. In Py3.0, dict.items becomes a synonym for dict.iteritems and programs that don't care about compat with 2.X can just use dict.items from then on. And everybody can be happy. A small number of redundant methods is a small price to pay for compatibility. James ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] IDLE development
On 9/11/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 9/10/05, Noam Raphael <[EMAIL PROTECTED]> wrote: > > I and my colleges use IDLE intensively - that is, a heavily patched > > IDLE. It includes my patch and many other improvements made by me and > > my friends. > > > > The improved IDLE is MUCH better than the standard IDLE, especially > > for interactive work. > > Could it be that this is a rather subjective judgement? It wouldn't be > the first time that someone pushing for their personal set of > functionality changes is overlooking the needs of other user groups. > I don't think so, since: 1. These are added features, not functionality changes. 2. There are quite a lot of people using the improved IDLE where I work, and I never heard anyone saying he prefers the standard IDLE - on the contrary, many are asking how they can use the improved IDLE in their homes. 3. Kurt agreed to integrate the change - he just didn't do it. > > Since we would like to share our work with the > > rest of the world, if nothing is changed we would start a new IDLE > > fork soon, perhaps at python-hosting.com. > > I have no problem with this. You might be able to save yourself some > maintenance work by structuring your version as a set of subclasses > rather than a set of patches (even if you distribute it as a complete > working program). Many people have needs that aren't met by standard > Python; they write their own modules or extensions and distribute > these independently from Python; your case probably isn't all that > different. > I think that rewriting the patches as subclasses will be a lot of work, and won't be a very good idea - if you change one line in a function, copy-pasting it to a subclass and changing the line seems a little weird for me - not to mention the cases where some refactoring needs to be done. I think we will be talking about a separate package - say, idleforklib instead of idlelib. You can always run diff to find the differences between the two packages. > Often the needs of certain user groups and the development speeds of > such 3rd party modules are so different that it simply doesn't make > sense to fold them in the Python distribution anyway -- consider what > you would have to do if Kurt accepted your patches: you'll still have > to wait until Python 2.5 is released before others can benefit from > your changes, and if you come up with an improvement after that > release, your next chance will be 18 months later... > I don't think so - if IDLE is developed on the Python CVS, we can still distribute a stand-alone package with IDLE from the CVS head, for eager people. All others will get the changes a year later, which isn't that bad. Perhaps it can even be less than a year - since IDLE is a GUI application and not a library, so there isn't a lot of backward compatibility to maintain, it seems to me that updated versions can be shipped also with new minor versions of Python. The advantages of developing IDLE on the Python CVS are that there is no need to synchronize two versions, and a wider audience. Of course, after you see the improved IDLE you will surely decide to immediately import it into the Python CVS, so there's not much of a problem... :) Noam ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] IDLE development
On 9/11/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > Often the needs of certain user groups and the development speeds of > > such 3rd party modules are so different that it simply doesn't make > > sense to fold them in the Python distribution anyway -- consider what > > you would have to do if Kurt accepted your patches: you'll still have > > to wait until Python 2.5 is released before others can benefit from > > your changes, and if you come up with an improvement after that > > release, your next chance will be 18 months later... > > Isn't separate distribution the way the *current* version of Idle was > developed? I seem to recall it existing as IDLEFork for a long time so that it > could have a more rapid release cycle before being rolled into the main > distribution. Yes, it is. I answered on the way to maintain a more rapid release cycle of IDLE when developed in the Python CVS on my post in reply to Guido. > > This approach also allows a wider audience to asess the subjective benefits of > any changes made - many more people will download and try out a separate IDE > than will download and try out a patch to the main distribution. I'm such a > one, even though I believe my main problems with Idle lie in the Tcl/tk > toolkit (so I don't expect any application level changes to alter my opinion > much). Can you please explain what are these problems? A big problem with Tcl/tk is that only one function call can be triggered by an event, and I solved it for IDLE by writing a wrapper around Tkinter classes, which calls all binded function calls on an event. This, for example, allows the yellow CallTip windows to disappear when the IDLE window loses focus, instead of staying above all other windows. Thanks, Noam ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
