Re: [Python-Dev] bool conversion wart?
Neal Becker wrote: > The fact that other numeric > types act this way leaves a reasonable expectation that bool will. But bool isn't really a numeric type in the same way that the others are. It's only a subtype of int for historical reasons. If it had been a part of Python from the beginning, it probably would have been a separate type altogether. Hmmm... is that something that should be revisited in 3.0? -- Greg ___ 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] [PATCH] Handling of scripts / substitution of python executable path
Hi!
For a long time, I have been annoyed by distutils behavior concerning
"scripts": I always put
#!/usr/bin/env python
into the first line in order to let the incredibly useful "env" program start
the right python version.
I know that it is quite evil to hardcode /usr/bin/python
or /usr/local/bin/python; I have seen dozens of #! hacks for finding e.g.
perl, and I was delighted to find /usr/bin/env, which solves the problem once
and for all. (And yes - it is always in /usr/bin/! ;-) )
Now distutils tries to be intelligent and "destroys" my nice #! lines, which
can be quite evil in complex setups, e.g. when you share your home directory
via NFS (or rsync/unison) between several environments with different python
installations. Furthermore, we are using the "module" system here at our
university, so that I can dynamically choose between half a dozen python
versions ("module" manages your PATH variables). Replacing the python path
turns nice, pure python scrips into platform-specific programs as you can see
here:
[EMAIL PROTECTED]:~ head -n1 ~/vigra/interactive/build/scripts-2.4/pyterm
#!/software/python-2.4.4/SuSE-9.0/bin/python
Note the SuSE-9.0 exec-prefix in the path; we are using several Linux and
Solaris versions here:
[EMAIL PROTECTED]:~/tmp/vi3build -> ls -1 /software/python-2.4.4/*/bin/python
/software/python-2.4.4/SuSE-10.0/bin/python*
/software/python-2.4.4/SuSE-9.0/bin/python*
/software/python-2.4.4/SunOS-5.8/bin/python*
I see that distutils as it is now does the right thing
* on Windows systems,
* on any system where /usr/bin/env is missing, or
* when the source file has a #! with a broken path.
What I propose is a minimal invasive change which keeps /usr/bin/env iff it is
in the #! line *and* exists on the current system. (A more brave change
would be to always use /usr/bin/env if it exists, but I think that is a topic
open for discussion.) Attached you'll find a patch which implements this; I
did not yet update tests/test_build_scripts.py however.
Comments? (I first posted this to distutils-sig but was told that distutils
is a bit neglected there, so I decided to try to push these simple patches in
via python-dev.)
Ciao, / /
/--/
/ / ANS
--- /software/python-2.4.4/lib/python2.4/distutils/command/build_scripts.py.orig 2007-01-02 14:06:37.0 +0100
+++ /software/python-2.4.4/lib/python2.4/distutils/command/build_scripts.py 2007-02-15 15:02:39.0 +0100
@@ -15,7 +15,7 @@
from distutils import log
# check if Python is called on the first line with this expression
-first_line_re = re.compile('^#!.*python[0-9.]*([ \t].*)?$')
+first_line_re = re.compile('^#! *(.*python[0-9.]*)([ \t].*)?$')
class build_scripts (Command):
@@ -89,23 +89,27 @@
match = first_line_re.match(first_line)
if match:
adjust = 1
-post_interp = match.group(1) or ''
+use_env = match.group(1).startswith("/usr/bin/env") and \
+ os.path.exists("/usr/bin/env")
+if use_env and match.group(1) == "/usr/bin/env python":
+adjust = 0
+post_interp = match.group(2) or ''
if adjust:
+if use_env:
+python_executable = "/usr/bin/env python"
+elif not sysconfig.python_build:
+python_executable = self.executable
+else:
+python_executable = os.path.join(
+sysconfig.get_config_var("BINDIR"),
+"python" + sysconfig.get_config_var("EXE"))
+
log.info("copying and adjusting %s -> %s", script,
self.build_dir)
if not self.dry_run:
outf = open(outfile, "w")
-if not sysconfig.python_build:
-outf.write("#!%s%s\n" %
- (self.executable,
-post_interp))
-else:
-outf.write("#!%s%s\n" %
- (os.path.join(
-sysconfig.get_config_var("BINDIR"),
-"python" + sysconfig.get_config_var("EXE")),
-post_interp))
+outf.write("#!%s%s\n" % (python_executable, post_interp))
outf.writelines(f.readlines())
outf.close()
if f:
___
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] Old bug still unfixed? [ python-Patches-1183712 ] package_data chops off first char of default package
Hi!
(I first posted this to distutils-sig but was told that distutils is a bit
neglected there, so I decided to try to push these simple patches in via
python-dev.) Lately, a student came to me complaining about an old distutils
bug which
bit him:
http://mail.python.org/pipermail/patches/2006-August/020642.html
The patch is quite trivial and cannot possibly break something AFAICS, so
could someone please apply it? (Hmm, now that I write this; we are still
using python 2.4.4 here, so maybe it has been fixed in between?)
Ciao, / /
/--/
/ / ANS
--- ./lib/python2.4/distutils/command/build_py.py~ 2007-01-02 14:06:37.823514000 +0100
+++ ./lib/python2.4/distutils/command/build_py.py 2007-02-14 13:56:45.972372000 +0100
@@ -114,7 +114,7 @@
build_dir = os.path.join(*([self.build_lib] + package.split('.')))
# Length of path to strip from found files
-plen = len(src_dir)+1
+plen = src_dir and len(src_dir)+1 or 0
# Strip directory from globbed filenames
filenames = [
___
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] [Python-checkins] r53860 - peps/trunk/pep-0000.txt peps/trunk/pep-0358.txt
On 2/22/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> [-python-checkins, +python-dev]
>
> On 2/22/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > > __setitem__
> > > __setslice__
> > > append
> > > count
> > > +decode
> > > +endswith
> > > extend
> > > +find
> > > index
> > > insert
> > > +join
> > > +partition
> > > remove
> > > +replace
> > > +rindex
> > > +rpartition
> > > +split
> > > +startswith
> > > +rfind
> > > +rindex
> > > +rsplit
> > > +translate
> > What sort of arguments do they take?
> You should be able to infer this from what the corresponding str or
> list methods do -- always substituting bytes for those, and int for
> the single element.
...
> > Single integers? startswith(ord('A'))
>
> TypeError (this is the same as the previous.)
>>> "asdf".index("df") == "asdf".index("d")
Assuming :
>>> data = bytes("asdf", 'ASCII')
Are you saying that, even for the single-char call, I must write:
>>> data.index(bytes("d", 'ASCII'))
instead of:
>>> data.index("d")
or even:
>>> data.index(ord("d"))
-jJ
___
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] [PATCH] Handling of scripts / substitution of python executable path
On Fri, 23 Feb 2007 15:36:50 +0100, Hans Meine <[EMAIL PROTECTED]> wrote: >Hi! > > [snip - distutils should leave #!/usr/bin/env python alone] > >Comments? (I first posted this to distutils-sig but was told that distutils >is a bit neglected there, so I decided to try to push these simple patches in >via python-dev.) How about a distutils installation command line option to tell it to use this behavior? People with unusual environments can select it. Jean-Paul ___ 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] [Python-checkins] r53860 - peps/trunk/pep-0000.txt peps/trunk/pep-0358.txt
The latest version of the PEP clarifies that both are allowed.
On 2/23/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 2/22/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > [-python-checkins, +python-dev]
> >
> > On 2/22/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > > > __setitem__
> > > > __setslice__
> > > > append
> > > > count
> > > > +decode
> > > > +endswith
> > > > extend
> > > > +find
> > > > index
> > > > insert
> > > > +join
> > > > +partition
> > > > remove
> > > > +replace
> > > > +rindex
> > > > +rpartition
> > > > +split
> > > > +startswith
> > > > +rfind
> > > > +rindex
> > > > +rsplit
> > > > +translate
>
> > > What sort of arguments do they take?
>
> > You should be able to infer this from what the corresponding str or
> > list methods do -- always substituting bytes for those, and int for
> > the single element.
> ...
> > > Single integers? startswith(ord('A'))
> >
> > TypeError (this is the same as the previous.)
>
> >>> "asdf".index("df") == "asdf".index("d")
>
> Assuming :
> >>> data = bytes("asdf", 'ASCII')
>
> Are you saying that, even for the single-char call, I must write:
> >>> data.index(bytes("d", 'ASCII'))
>
> instead of:
> >>> data.index("d")
>
> or even:
> >>> data.index(ord("d"))
>
> -jJ
>
--
--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] [PATCH] Handling of scripts / substitution of python executable path
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 23, 2007, at 9:55 AM, Jean-Paul Calderone wrote: > On Fri, 23 Feb 2007 15:36:50 +0100, Hans Meine > <[EMAIL PROTECTED]> wrote: >> Hi! >> >> [snip - distutils should leave #!/usr/bin/env python alone] >> >> Comments? (I first posted this to distutils-sig but was told that >> distutils >> is a bit neglected there, so I decided to try to push these simple >> patches in >> via python-dev.) > > How about a distutils installation command line option to tell it > to use this > behavior? People with unusual environments can select it. This would be best I think. There's a related problem here. Many operating systems (e.g. various Linux distros) provide system scripts written in Python and they incorrectly use /usr/bin/env. The problem is that if you have your own version of Python earlier in your $PATH, you can break these scripts. This happens when say your /usr/local/ bin/python doesn't have the packages that your /usr/bin/python expects. I've hit this quite a few times on Gentoo for example. In these cases, you really do want the #! line to point to the OS's version of Python rather than whatever random installation is on your $PATH. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRd8//XEjvBPtnXfVAQLZKQP+NvcjMIT4tCZtOIPWo8Kj1JMp5iX0Nqib BBXPgDtncJ6VvITclbYLAmitPhwkDddHXgNIHoj2lY9HJildfOkDQxVpDRTvrEvd hlIW4z7S6SmlrvxJYSB2jGSpkNkVRo8UpZKsmU0BWFBE9t6Tnw+ofItuKIF1TlWS unSo4LceXFo= =wiLG -END PGP SIGNATURE- ___ 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] bool conversion wart?
Neal Becker schrieb: > Doesn't this seem a bit inconsisent? Please don't ask such questions. Instead, formulate them as "I would have expected the result to be X instead. Why is the result Y?" (if that is actually the question you meant to ask) IOW, what does it help you if somebody answers "yes" to your question? Regards, Martin ___ 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] bool conversion wart?
Greg Ewing schrieb: > But bool isn't really a numeric type in the same way > that the others are. It's only a subtype of int for > historical reasons. If it had been a part of Python > from the beginning, it probably would have been a > separate type altogether. > > Hmmm... is that something that should be revisited > in 3.0? I specifically asked the question when unifying ints and longs for 3.0 (as int went away, the question was what True and False ought to be). Guido pronounced that it is deliberate that they are "integer-like", and should continue to inherit from the integer type. One idiom that people use a lot is foo[b], where b is a boolean. Regards, Martin ___ 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] [PATCH] Handling of scripts / substitution of python executable path
Hans Meine schrieb: > For a long time, I have been annoyed by distutils behavior concerning > "scripts": I always put > #!/usr/bin/env python > into the first line in order to let the incredibly useful "env" program start > the right python version. > > I know that it is quite evil to hardcode /usr/bin/python No. The current distutils behaviour is very deliberate, intentional, and has undergone a number of iterations to arrive at this point. While it is true that you would normally use /usr/bin/env for scripts that you *distribute*, it's not true that you should use that for scripts that you *install*. Instead, the script that you install will likely depend on the specific installation of Python: the script will likely use modules that are only installed in a single location. So the installed scripts need to hard-code the path to the interpreter, or else they break if somebody changes the path and suddenly picks up a different Python. Notice that it may not just be that the Python is a different version (on which the script won't work); it may also be that the it won't work on a different installation of the *same* Python version, since it requires libraries not available in this other installation. So the default must stay as it is. Regards, Martin ___ 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] Old bug still unfixed? [ python-Patches-1183712 ] package_data chops off first char of default package
Hans Meine schrieb: > (I first posted this to distutils-sig but was told that distutils is a bit > neglected there, so I decided to try to push these simple patches in via > python-dev.) Lately, a student came to me complaining about an old distutils > bug which > bit him: > http://mail.python.org/pipermail/patches/2006-August/020642.html > > The patch is quite trivial and cannot possibly break something AFAICS, so > could someone please apply it? (Hmm, now that I write this; we are still > using python 2.4.4 here, so maybe it has been fixed in between?) See https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1183712&group_id=5470 The last comment is from jimjjewet, and he claims that the patch is still incomplete. There is no response to that claim so far, by either the patch author nor anybody else. I still believe that the patch is unnecessary, i.e. it fixes a problem which shouldn't arise in the first place. Regards, Martin ___ 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] Old bug still unfixed? [ python-Patches-1183712 ] package_data chops off first char of default package
At 10:35 PM 2/23/2007 +0100, Martin v. Löwis wrote: >Hans Meine schrieb: > > > (I first posted this to distutils-sig but was told that distutils is a bit > > neglected there, so I decided to try to push these simple patches in via > > python-dev.) Lately, a student came to me complaining about an old > distutils > > bug which > > bit him: > > http://mail.python.org/pipermail/patches/2006-August/020642.html > > > > The patch is quite trivial and cannot possibly break something AFAICS, so > > could someone please apply it? (Hmm, now that I write this; we are still > > using python 2.4.4 here, so maybe it has been fixed in between?) > >See > >https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1183712&group_id=5470 > >The last comment is from jimjjewet, and he claims that the patch is >still incomplete. There is no response to that claim so far, by >either the patch author nor anybody else. I still believe that the >patch is unnecessary, i.e. it fixes a problem which shouldn't >arise in the first place. I believe you're correct. If anything, the fix should be to disallow an empty string being listed in the 'packages' argument to 'setup()'. I've added some notes to the bug to also show why Jim's concerns about absolute paths and trailing /'s don't actually come into play for this code. ___ 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] bool conversion wart?
Martin v. Löwis wrote: > One idiom that people use a lot is foo[b], where > b is a boolean. Could that be addressed using the new __index__ mechanism? -- Greg ___ 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] NOARGS_NULL
My only objection (which is a minor one) is with the 'NOARGS_NULL' name. Caps don't fit the normal style rules, and 'noargs_null' doesn't make much sense to me. 'unused' strikes me as a clearer name (or 'noargs_unused' or 'args_unused' or such.) It should be fine to fix this in 2.5 as well (as long as arguments previously ignored don't suddenly raise exceptions, but it doesn't sound like that's happening at all.) On 2/18/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: Patch #1648268 corrects a huge load of errors in Python wrt. incorrect function pointers (i.e. functions called with a different signature then declared, through pointers). The rationale for this patch is that the submitter apparently has a platform where Python crashes in the face of these errors. I believe the patch is correct, and would like to apply it. The patch also renames many function arguments: parameters in a METH_NOARGS function get consistently named NOARGS_NULL (currently often called 'unused' or 'noargs'); the second parameter to getters gets consistently named 'closure' (it's called closure in many places already, and 'unused' in others). I would also apply this part of the change, and both to the trunk and Python 2.5. Objections? Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/thomas%40python.org -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] C decimal project.
Hi, Last holidays I was writting C decimal during summer of code 2006, I planned to take a breath for 1-2 months and then continue work, but well, things didn't go the way I planned. Now I am ready to continue work, I mainly plan to optimize it a little bit (top priority would be cut some copying) and add C api, so C decimal would eventually leave sandbox. My question is - am I permitted to just continue work on svn? Or there is something I have to do before that? Any sugestions etc. would be appreciated. Thanks in advance and best regards, Mateusz Rukowicz. ___ 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] Unicode command line parameter missing
Python Versions: 2.5 and trunk Browsing through the code this evening and noticed a discrepancy between the command line parameters listed with --help and those truly available in the code. Namely with the -U Unicode flag.. The -U option was added back in 2000, rev 15296 and mention of it was removed in rev 25288. Should the -U option still be handled from the command line? Python 2.5 Session without flag: python Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. a = "monty" a 'monty' Python 2.5 Session with flag: python -U Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. a = "monty" a u'monty' Joseph Armbruster ___ 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] A "record" type (was Re: Py2.6 ideas)
Josiah Carlson wrote: > Larry Hastings <[EMAIL PROTECTED]> wrote: > >> Josiah Carlson wrote: >> >>> one thing to note with your method - you can't guarantee the order >>> of the attributes as they are being displayed. >>> >> Actually, my record type *can*; see the hack using the __names__ field. > Actually, it *can't*. The ordering of the dict produced by the **kwargs > arguments is exactly same as a regular dictionary. Just to set the record.py straight, more for posterity than anything else: Actually, it *does*, because my prototype has explicit support for imposing such an ordering. That's what the "__names__" field is used for--it's an optional array of field names, in the order you want them displayed from __repr__(). Mr. Carlson's posting, while correct on general principles, was just plain wrong about my code; I suspect he hadn't bothered to read it, and instead based his reply on speculation about how it "probably" worked. My "record" prototype has no end of failings, but an inability to "guarantee the order of the attributes as they are being displayed" is simply not one of them. /larry/ ___ 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] A "record" type (was Re: Py2.6 ideas)
Larry Hastings <[EMAIL PROTECTED]> wrote: > > Josiah Carlson wrote: > > Larry Hastings <[EMAIL PROTECTED]> wrote: > > > >> Josiah Carlson wrote: > >> > >>> one thing to note with your method - you can't guarantee the order > >>> of the attributes as they are being displayed. > >>> > >> Actually, my record type *can*; see the hack using the __names__ field. > > Actually, it *can't*. The ordering of the dict produced by the **kwargs > > arguments is exactly same as a regular dictionary. > > Just to set the record.py straight, more for posterity than anything else: > > Actually, it *does*, because my prototype has explicit support for > imposing such an ordering. That's what the "__names__" field is used > for--it's an optional array of field names, in the order you want them > displayed from __repr__(). > > Mr. Carlson's posting, while correct on general principles, was just > plain wrong about my code; I suspect he hadn't bothered to read it, and > instead based his reply on speculation about how it "probably" worked. No, I just didn't notice the portion of your code (in the 'if __name__ == "__main__" block) that modified the __names__ field after record construction. In the other record types that were offered by Steven and Raymond, the point is to have an ordering that is fixed. I didn't notice it because I expected that it was like Raymond and Steven's; static layout after construction - but that is not the case. - Josiah ___ 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] bool conversion wart?
Greg Ewing schrieb: >> One idiom that people use a lot is foo[b], where >> b is a boolean. > > Could that be addressed using the new __index__ mechanism? That would be possible, yes. Martin ___ 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] NOARGS_NULL
Thomas Wouters schrieb: > My only objection (which is a minor one) is with the 'NOARGS_NULL' name. > Caps don't fit the normal style rules, and 'noargs_null' doesn't make > much sense to me. 'unused' strikes me as a clearer name (or > 'noargs_unused' or 'args_unused' or such.) The point clearly is that the submitter wants the code to explain what the meaning of the parameter is, and why it is unused. NOARGS_NULL is intended to express that the argument will always be NULL (and thus obviously irrelevant). It's easy to see from the code that the parameter is unused, so it doesn't give much information calling it unused; OTOH it may not be so obvious what information the caller will provide (i.e. whether it's an argument tuple, or the "closure" field). > It should be fine to fix this > in 2.5 as well (as long as arguments previously ignored don't suddenly > raise exceptions, but it doesn't sound like that's happening at all.) That change does not change behaviour at all. Regards, Martin ___ 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] C decimal project.
Mateusz Rukowicz schrieb: > Last holidays I was writting C decimal during summer of code 2006, I > planned to take a breath for 1-2 months and then continue work, but > well, things didn't go the way I planned. Now I am ready to continue > work, I mainly plan to optimize it a little bit (top priority would be > cut some copying) and add C api, so C decimal would eventually leave > sandbox. > > My question is - am I permitted to just continue work on svn? Or there > is something I have to do before that? Any sugestions etc. would be > appreciated. As long as you restrict yourself to making only those changes that you originally wanted to make, you can keep the commit privilege as long as you need it. It would be nice if you would let us (Neal Norwitz or myself, or whoever manages svn accounts then) know if you find that you won't contribute to the project anymore, but there are many committers who have "silently" withdrawn, and that's really no problem, either. Regards, Martin ___ 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] Unicode command line parameter missing
Joseph Armbruster schrieb: > The -U option was added back in 2000, rev 15296 and mention of it was > removed > in rev 25288. Should the -U option still be handled from the command line? Yes. The original goal of the -U command line (find out what happens if all strings were unicode) still remains at the moment. It may be sensible to remove it when Python 3 has solved the issue in some other way, but then, removing it may cause unnecessary breakage, so it can just as well stay throughout 2.x. Regards, Martin ___ 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
