Re: [Python-Dev] Bug Day outcome
Excellent ! When will be the next one ? :-) On Jan 20, 2008 2:14 AM, A.M. Kuchling <[EMAIL PROTECTED]> wrote: > Today's bug day was a great success. Experienced people like Georg, > Facundo, and Gregory P. Smith participated, and we also had people who > submitted their first patches, some of which got applied today, too. > Hopefully we'll see those people again. > > As of this writing, 37 issues were closed today, leaving 1300 open. > (I saved a search in Roundup to list the bugs closed today.) > > --amk > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/qgallet%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bug Day outcome
Quentin Gallet-Gilles wrote: > Excellent ! When will be the next one ? :-) Everyday can be a bug day. :) Nobody is going to stop you from squalling through the bug tracker. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rational approximation methods
On 19/01/2008, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote: > The first returns the closest rational whose denominator is less than > a given integer. [...] > The second returns the simplest rational within some distance. Both of these are likely to be of limited use. The most common usage I know of is to make a "sensible" rational from a float (i.e., a DWIM style conversion 0.1 -> 1/10) or to provide readable output. On the other hand, both are subtle to implement, so having a standard implementation saves people having to code (and debug) their own. I suspect that simplest within a particular distance is the form that is most often wanted, but I don't have any good evidence for that feeling. Putting both in might help people to realise that there *is* a choice. Given that you have implemented them, I'd say leave them in. And I like the names trim and approximate, as given in the code you referenced. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What to do for bytes in 2.6?
On Sat, Jan 19, 2008, Guido van Rossum wrote: > > I believe that a constraint should be that by default (without -3 or a > __future__ import) str and bytes should be the same thing. Or, another > way of looking at this, reads from binary files and reads from sockets > (and other similar things, like ctypes and mmap and the struct module, > for example) should return str instances, not instances of a str > subclass by default -- IMO returning a subclass is bound to break too > much code. This makes perfect sense to me. And yet, I also like the idea that b""+u"" raises an exception. I have a suggestion, then: for 2.6, let's make bytes a subclass of string whose only difference is that it contains a flag. I don't care whether b""+u"" raises an exception. This should be enough for people on an accelerated 3.0 conversion schedule, and they can write their own test for the flag if they care. For 2.7, we can start tightening up. b""+u"" can raise an exception, and the socket module might use a RETURN_BYTES variable. To put it another way, I don't think we should consider 2.6 the stopping point for 2.x/3.x conversion help. There's nothing wrong with planning for features to go into 2.7 -- just as several PEPs in the past have had multi-version planning. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "All problems in computer science can be solved by another level of indirection." --Butler Lampson ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bug Day outcome
Christian Heimes wrote: > Quentin Gallet-Gilles wrote: >> Excellent ! When will be the next one ? :-) > > Everyday can be a bug day. :) > Nobody is going to stop you from squalling through the bug tracker. I enjoyed the bug day a lot and will certainly come back for more when I can spare a little time. One question there: Will the "easy" keyword in roundup be maintained further, i.e. will new easy bugs be marked in the future? That would be very useful for neophyte contributors. Malte ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bug Day outcome
Malte Helmert wrote: > One question there: Will the "easy" keyword in roundup be maintained > further, i.e. will new easy bugs be marked in the future? That would be > very useful for neophyte contributors. Yes, we will keep marking easy bugs with the "easy" keyword. Christian ___ Python-Dev mailing list Python-Dev@python.org 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: per user site-packages directory
Op zondag 13-01-2008 om 10:45 uur [tijdzone +0100], schreef Christian Heimes: > Gregory P. Smith wrote: > > My main suggestion was going to be the ability to turn it off as you already > > mentioned. However, please consider leaving it off by default to avoid > > problems for installed python scripts importing user supplied code. For > > shared hosting environments where this becomes really useful users can > > easily add the -s (or whatever flag is chosen) to their programs > > themselves. I don't know what that'd mean on windows where #! lines don't > > exist. Yet another file extension to imply the flag (yuck)? A .cmd wrapper > > script to run python with the flag (ugh)? > > So you prefer to make the per use site-package directory an opt-in > option? I prefer it as an opt-out option. It's enabled by default, > unless the user disables the feature with -s. One possible issue with enabling it by default could be that less-experienced users can accidentally break the system configuration tools written in python used by several linux distros (Ubuntu, Gentoo, Fedora/Red Hat, ...). There should be a way for distro developers to make sure the users local 'site-packages' is *not* used when running those tools. I'd rather have to set/uncomment an environment variable on my system than having 100 "normal" users break their systems accidentally... ;-) -- Jan Claeys ___ Python-Dev mailing list Python-Dev@python.org 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: per user site-packages directory
Op zaterdag 12-01-2008 om 00:27 uur [tijdzone +0100], schreef Christian Heimes: > Specification > = [...] > user configuration directory > >Usually the parent directory of the user site directory. It's meant >for Python version specific data like config files. > >Windows: %APPDATA%/Python/Python26 >Mac: ~/Library/Python/2.6 >Unix: ~/.local/lib/python2.6 What do you mean by "configuration directory"? IMHO configuration files on linux/unix should go into ~/.python2.6 or ~/.config/python2.6 or something like that? (I would never look in a directory named 'lib' for configuration files.) -- Jan Claeys ___ Python-Dev mailing list Python-Dev@python.org 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: per user site-packages directory
Jan Claeys wrote: > What do you mean by "configuration directory"? IMHO configuration files > on linux/unix should go into ~/.python2.6 or ~/.config/python2.6 or > something like that? It's already renamed in the PEP: http://www.python.org/dev/peps/pep-0370/#specification Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bug Day outcome
A.M. Kuchling schrieb: > Today's bug day was a great success. Experienced people like Georg, > Facundo, and Gregory P. Smith participated, and we also had people who > submitted their first patches, some of which got applied today, too. > Hopefully we'll see those people again. > > As of this writing, 37 issues were closed today, leaving 1300 open. > (I saved a search in Roundup to list the bugs closed today.) Since I was a bit incapacitated yesterday, I continued the bug day on my own and closed 17 more issues today. Sadly, the number of open issues is now 1715 since Martin imported those from SF.net which weren't in the export in the first round. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list Python-Dev@python.org 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: per user site-packages directory
-On [20080116 07:15], Oleg Broytmann ([EMAIL PROTECTED]) wrote: > The site only mentions $HOME/.local/share, there is no $HOME/.local/bin >at the site. As was mentioned earlier in the thread. Only $HOME/.local/share was in the Free Desktop specification. The bin is something that got introduced in this thread. It makes sense to stick to hier(7) for this sort of thing. Although the entire concept of a $HOME/.local was new to me as well and is not mandated at all in POSIX or other circles aside from, apparently, the Free Desktop folks. Pendantic note: ~ is an expansion character, the correct variable to talk about is HOME (see IEEE Std 1003.1, 2004 section 2.5.3 and 2.6.1). -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ Peace comes from within. Do not seek it without. - Buddha ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] #! magic (was PEP: per user site-packages directory)
On Sun, Jan 20, 2008 at 06:00:31PM +0100, Christian Heimes wrote: > #!/usr/bin/env python -E -s On most Unicies #! magic may have only one parameter after the program; the program here is env, the parameter is python, and that's all. Adding python options will result in different errors - some platforms silently ignores the options, some reports an error, some tries to find "python -E -s" in the PATH and report "Bad command or file name". Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] #! magic (was PEP: per user site-packages directory)
-On [20080120 18:12], Oleg Broytmann ([EMAIL PROTECTED]) wrote: > On most Unicies #! magic may have only one parameter after the program; >the program here is env, the parameter is python, and that's all. Adding >python options will result in different errors - some platforms silently >ignores the options, some reports an error, some tries to find "python -E -s" >in the PATH and report "Bad command or file name". IEEE Std 1003.1, 2004: The shell reads its input from a file (see sh), from the -c option or from the system() and popen() functions defined in the System Interfaces volume of IEEE Std 1003.1-2001. If the first line of a file of shell commands starts with the characters "#!", the results are unspecified. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ I dream of Love as Time runs through my hand... ___ Python-Dev mailing list Python-Dev@python.org 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: per user site-packages directory
Jan Claeys wrote: > There should be a way for distro developers to make sure the users local > 'site-packages' is *not* used when running those tools. There is an option. Those tools should use the -E and -s argument: #!/usr/bin/env python -E -s Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] #! magic
On Sun, Jan 20, 2008 at 06:25:57PM +0100, Jeroen Ruigrok van der Werven wrote: > -On [20080120 18:12], Oleg Broytmann ([EMAIL PROTECTED]) wrote: > > On most Unicies #! magic may have only one parameter after the program; > >the program here is env, the parameter is python, and that's all. Adding > >python options will result in different errors - some platforms silently > >ignores the options, some reports an error, some tries to find "python -E -s" > >in the PATH and report "Bad command or file name". > > IEEE Std 1003.1, 2004: > > The shell reads its input A shell has nothing to do with it as it is the OS (exec system call) that upon reading the magic of the file sees #! and executes the program (up to the first space) and pass to the program the first (and the only) parameter. #! /usr/bin/env python -O [trying to execute the script on Linux] /usr/bin/env: python -O: No such file or directory Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org 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-Dev Digest, Vol 54, Issue 57
Op woensdag 16-01-2008 om 02:33 uur [tijdzone +0100], schreef Christian Heimes: > Bill Janssen wrote: > > Good point, but I prefer ~/Library/Python to either of these. > > ~/Library/ is a Mac OS X thing. I haven't seen it on other Unix systems. There is (at least) one linux distro using it, but it's not very well-known. > I *could* add yet another environment variable PYTHONUSERHOME to set the > base path but I prefer not. A solution might be a way for python distributors to set the default location , and then provide PYTHONUSERHOME for stubborn users to override that. ;) -- Jan Claeys ___ Python-Dev mailing list Python-Dev@python.org 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-Dev Digest, Vol 54, Issue 57
On Sun, Jan 20, 2008 at 06:46:31PM +0100, Jan Claeys wrote: > Op woensdag 16-01-2008 om 02:33 uur [tijdzone +0100], schreef Christian > Heimes: > > Bill Janssen wrote: > > > Good point, but I prefer ~/Library/Python to either of these. > > > > ~/Library/ is a Mac OS X thing. I haven't seen it on other Unix systems. > > There is (at least) one linux distro using it, but it's not very > well-known. Gobo Linux? Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org 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: per user site-packages directory
Op zondag 20-01-2008 om 18:01 uur [tijdzone +0100], schreef Christian Heimes: > Jan Claeys wrote: > > What do you mean by "configuration directory"? IMHO configuration files > > on linux/unix should go into ~/.python2.6 or ~/.config/python2.6 or > > something like that? > > It's already renamed in the PEP: > http://www.python.org/dev/peps/pep-0370/#specification So this is stuff that should never be changed by the user? -- Jan Claeys ___ Python-Dev mailing list Python-Dev@python.org 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-Dev Digest, Vol 54, Issue 57
Op zondag 20-01-2008 om 20:46 uur [tijdzone +0300], schreef Oleg Broytmann: > On Sun, Jan 20, 2008 at 06:46:31PM +0100, Jan Claeys wrote: > > Op woensdag 16-01-2008 om 02:33 uur [tijdzone +0100], schreef Christian > > Heimes: > > > ~/Library/ is a Mac OS X thing. I haven't seen it on other Unix systems. > > > > There is (at least) one linux distro using it, but it's not very > > well-known. > >Gobo Linux? Now that I think about it, I'm not sure they use it under $HOME too, but I was thinking about that distro, yes, as they use such a scheme for the rest of their system (and it seems natural to do so throughout then). -- Jan Claeys ___ Python-Dev mailing list Python-Dev@python.org 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: per user site-packages directory
Jeroen Ruigrok van der Werven wrote: > Pendantic note: ~ is an expansion character, the correct variable to talk > about is HOME (see IEEE Std 1003.1, 2004 section 2.5.3 and 2.6.1). Most Python developers should the meaning of "~". Should I replace ~ with $HOME for those who don't have as much experience with Unix as we? Christian ___ Python-Dev mailing list Python-Dev@python.org 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: per user site-packages directory
Jan Claeys wrote: > So this is stuff that should never be changed by the user? ~/.local/lib/python2.6 has the same semantics as /usr/local/lib/python2.6 except it's a per user directory and not per machine. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] #! magic
On Sun, Jan 20, 2008 at 07:30:03PM +0100, Christian Heimes wrote: > Oleg Broytmann wrote: > > #! /usr/bin/env python -O > > > >[trying to execute the script on Linux] > > > > /usr/bin/env: python -O: No such file or directory > > > > Oleg. > > Oh right. I was sure that I've seen a shebang with options somewhere. It > might have been a shell script or a perl script. Yes, one can write #! /usr/bin/python -O This works. The OS (exec system call) splits the string into a program (python) and a single parameter (-O), and python knows how to handle -O. The problem with #! /usr/bin/env python -O is that exec splits it into a program (env) and a single parameter (python -O) and env doesn't know how to run "python -O". > Yet another python executable could solve the issue I doubt it. It is env that doesn't know how to run "python -O" in my example, not python's problem. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Priorities in the tracker
After some months of tracker operation, I'd like to discuss one aspect of the tracker schema: priorities. Each issue has a severity and a priority. The severity is assigned by the submitter, defaults to normal, and indicates how serious the issue impacts him and the community. The priority is assigned by a developer (and cannot be set by a "mere" user), and indicates how quickly this issue must be processed. The priority is initially unset, requiring a developer to perform screening. It appears that developers rarely set the priority, leaving the issues formally unscreened. So what should we do? Leave things as-is? Drop the notion of priority? Change our process to make sure priorities do get set (and honored)? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] #! magic
Oleg Broytmann wrote:
>A shell has nothing to do with it as it is the OS (exec system call)
> that upon reading the magic of the file sees #! and executes the program
> (up to the first space) and pass to the program the first (and the only)
> parameter.
>
> #! /usr/bin/env python -O
>
>[trying to execute the script on Linux]
>
> /usr/bin/env: python -O: No such file or directory
>
> Oleg.
Oh right. I was sure that I've seen a shebang with options somewhere. It
might have been a shell script or a perl script.
Yet another python executable could solve the issue, named "pythons" as
python secure.
/*
gcc -DNDEBUG -g -O2 -Wall -Wstrict-prototypes -IInclude -I. -pthread
-Xlinker -lpthread -ldl -lutil -lm -export-dynamic -o pythons2.6
pythons.c libpython2.6.a
*/
#include "Python.h"
int main(int argc, char **argv) {
/* disable some possible harmful features */
Py_IgnoreEnvironmentFlag++;
Py_NoUserSiteDirectory++;
Py_InteractiveFlag -= INT_MAX;
Py_InspectFlag -= INT_MAX;
return Py_Main(argc, argv);
}
$ ./pythons2.6
Python 2.6a0 (:59956M, Jan 14 2008, 22:09:17)
[GCC 4.2.1 (Ubuntu 4.2.1-5ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.flags
sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0,
inspect=-2147483647, interactive=-2147483647, optimize=0,
dont_write_bytecode=0, no_user_site=1, no_site=0, ingnore_environment=1,
tabcheck=0, verbose=0, unicode=0)
Christian
___
Python-Dev mailing list
Python-Dev@python.org
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-Dev Digest, Vol 54, Issue 57
On Sun, Jan 20, 2008 at 07:34:02PM +0100, Jan Claeys wrote: > Op zondag 20-01-2008 om 20:46 uur [tijdzone +0300], schreef Oleg > Broytmann: > > On Sun, Jan 20, 2008 at 06:46:31PM +0100, Jan Claeys wrote: > > > Op woensdag 16-01-2008 om 02:33 uur [tijdzone +0100], schreef Christian > > > Heimes: > > > > ~/Library/ is a Mac OS X thing. I haven't seen it on other Unix systems. > > > > > > There is (at least) one linux distro using it, but it's not very > > > well-known. > > > >Gobo Linux? > > Now that I think about it, I'm not sure they use it under $HOME too, but > I was thinking about that distro, yes, as they use such a scheme for the > rest of their system (and it seems natural to do so throughout then). I don't know if they have a scheme for $HOME. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Priorities in the tracker
Martin v. Löwis wrote: > After some months of tracker operation, I'd like to discuss one aspect > of the tracker schema: priorities. > > Each issue has a severity and a priority. The severity is assigned by > the submitter, defaults to normal, and indicates how serious the issue > impacts him and the community. > > The priority is assigned by a developer (and cannot be set by > a "mere" user), and indicates how quickly this issue must be processed. > The priority is initially unset, requiring a developer to perform screening. > > It appears that developers rarely set the priority, leaving the issues > formally unscreened. > > So what should we do? Leave things as-is? Drop the notion of priority? > Change our process to make sure priorities do get set (and honored)? > It would appear useful to define some workflow aspects of issue processing, for example to ensure that priority gets set by a "responsible" reviewer. However whether such workflow should be imposed by automation or simply a discipline of development I'm not in a position to say. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Priorities in the tracker
On Jan 20, 2008 10:42 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > After some months of tracker operation, I'd like to discuss one aspect > of the tracker schema: priorities. > > Each issue has a severity and a priority. The severity is assigned by > the submitter, defaults to normal, and indicates how serious the issue > impacts him and the community. > > The priority is assigned by a developer (and cannot be set by > a "mere" user), and indicates how quickly this issue must be processed. > The priority is initially unset, requiring a developer to perform screening. > > It appears that developers rarely set the priority, leaving the issues > formally unscreened. > > So what should we do? Leave things as-is? Drop the notion of priority? > Change our process to make sure priorities do get set (and honored)? In my dream schema, severity becomes difficulty (e.g., easy, medium, hard, expert), type goes away, and priority changes to be release-based (e.g., RFE since those can occur whenever, next minor release, next micro release, immediately, etc.). I think priority should more be tied to our release cycles than this generic notion of importance. If it is important, we should try to get it done by a certain release. Let's have that fact directly reflected by the tracker. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Priorities in the tracker
Martin v. Löwis schrieb: > After some months of tracker operation, I'd like to discuss one aspect > of the tracker schema: priorities. > > Each issue has a severity and a priority. The severity is assigned by > the submitter, defaults to normal, and indicates how serious the issue > impacts him and the community. > > The priority is assigned by a developer (and cannot be set by > a "mere" user), and indicates how quickly this issue must be processed. > The priority is initially unset, requiring a developer to perform screening. > > It appears that developers rarely set the priority, leaving the issues > formally unscreened. > > So what should we do? Leave things as-is? Drop the notion of priority? > Change our process to make sure priorities do get set (and honored)? Christian currently does a good job of assigning the correct properties to new bugs. In any case, I'd prefer to keep a way to mark a bug as "high-priority" (meaning that it should be fixed before the next release) even if most of the bugs don't have an assigned priority. As to whether we need both severity and priority, I have no opinion. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Priorities in the tracker
Georg Brandl wrote: > Christian currently does a good job of assigning the correct properties > to new bugs. In any case, I'd prefer to keep a way to mark a bug as > "high-priority" (meaning that it should be fixed before the next release) > even if most of the bugs don't have an assigned priority. I've defined the priorities for me: low = nice to have feature normal = well ... pretty normal :) high = important, investigate the bug before the next release gets out urgent = bug breaks development or is a show stopper immediate = security issue or major development stopper Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rational approximation methods
On 1/20/08, Paul Moore <[EMAIL PROTECTED]> wrote: > Both of these are likely to be of limited use. The most common usage I > know of is to make a "sensible" rational from a float (i.e., a DWIM > style conversion 0.1 -> 1/10) or to provide readable output. On the > other hand, both are subtle to implement, so having a standard > implementation saves people having to code (and debug) their own. > > I suspect that simplest within a particular distance is the form that > is most often wanted, but I don't have any good evidence for that > feeling. Putting both in might help people to realise that there *is* > a choice. > > Given that you have implemented them, I'd say leave them in. And I > like the names trim and approximate, as given in the code you > referenced. I can't think of a use case for these either, but the first (limit_denominator) seems like a generalized round, and I suppose might be useful for something. -- Cheers, Leif ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bug Day outcome
A.M. Kuchling schrieb: > Today's bug day was a great success. Experienced people like Georg, > Facundo, and Gregory P. Smith participated, and we also had people who > submitted their first patches, some of which got applied today, too. > Hopefully we'll see those people again. > > As of this writing, 37 issues were closed today, leaving 1300 open. > (I saved a search in Roundup to list the bugs closed today.) Since this bug day was a relative success, I suggest to introduce a more-or-less regular schedule. Feb 23 would make a nice second bug day in 2008, wouldn't it? Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What to do for bytes in 2.6?
On Jan 20, 2008 6:56 AM, Aahz <[EMAIL PROTECTED]> wrote: > On Sat, Jan 19, 2008, Guido van Rossum wrote: > > > > I believe that a constraint should be that by default (without -3 or a > > __future__ import) str and bytes should be the same thing. Or, another > > way of looking at this, reads from binary files and reads from sockets > > (and other similar things, like ctypes and mmap and the struct module, > > for example) should return str instances, not instances of a str > > subclass by default -- IMO returning a subclass is bound to break too > > much code. > > This makes perfect sense to me. And yet, I also like the idea that > b""+u"" raises an exception. I have a suggestion, then: for 2.6, let's > make bytes a subclass of string whose only difference is that it contains > a flag. This still begs the question which standard APIs should return bytes. > I don't care whether b""+u"" raises an exception. This should > be enough for people on an accelerated 3.0 conversion schedule, and they > can write their own test for the flag if they care. Well, it being a subclass, it doesn't even need to have a flag, right? The class itself acts as a flag. But still, without support from built-in and standard library APIs I fear it's not going to be very useful. And fixing all the standard APIs to make the correct distinction is going to create exactly the ripple effect that Raymond so desperately wants to avoid -- and I agree, to the extent that rippling this through the stdlib is a waste of time from the stdlib's POV -- it's already been 3.0-ified. > For 2.7, we can start tightening up. b""+u"" can raise an exception, > and the socket module might use a RETURN_BYTES variable. > > To put it another way, I don't think we should consider 2.6 the stopping > point for 2.x/3.x conversion help. There's nothing wrong with planning > for features to go into 2.7 -- just as several PEPs in the past have had > multi-version planning. Personally, I very much doubt there will *be* a 2.7. I certainly don't expect to participate in its development the same way I am trying to steer 2.6. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org 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-3000] inst_persistent_id
I took Python-3000 out of the cc list as I originally just wanted to make them aware of this issue. On Jan 14, 2008, at 12:59 PM, Armin Rigo wrote: > Hi, > > On Sat, Jan 12, 2008 at 07:33:38PM -0500, Alexandre Vassalotti wrote: >> Well, in Python 3K, inst_persistent_id() won't be usable, since >> PyInstance_Type was removed. > > Looking at the code, inst_persistent_id() is just a confusing name. > It > has got nothing to do with PyInstance_Type; it's called for any object > type that cPickle.c doesn't know how to handle. It has to do with instances in a more general sense. > In fact, it seems that > cPickle.c never calls inst_persistent_id() for objects of type > PyInstance_Type... Hm, good point. At the time, all I cared about were ExtensionClass instances, which were akin to modern-day new-style instances. It doesn't make sense to not call this function for classic instances. This optimization is fairly useful. I propose to update the logic to call this function for classic instances too. I'm also open to renaming it if that would make people happier. :) Thoughts? Jim -- Jim Fulton Zope Corporation ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] #! magic (was PEP: per user site-packages directory)
* Oleg Broytmann <[EMAIL PROTECTED]> [2008-01-20 20:12:38 +0300]: > On Sun, Jan 20, 2008 at 06:00:31PM +0100, Christian Heimes wrote: > > #!/usr/bin/env python -E -s > >On most Unicies #! magic may have only one parameter after the program; > the program here is env, the parameter is python, and that's all. Adding > python options will result in different errors - some platforms silently > ignores the options, some reports an error, some tries to find "python -E -s" > in the PATH and report "Bad command or file name". Distro tools shouldn't be using /usr/bin/env in any case. Does #!/usr/bin/python -E -s work? -- mithrandi, i Ainil en-Balandor, a faer Ambar signature.asc Description: Digital signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Priorities in the tracker
Brett Cannon writes: > In my dream schema, severity becomes Then how does the user indicate how important it is to him? My severities (in an experimental roundup tracker I'm implementing) are 'inelegant', 'inconvenient', 'some work obstructed', 'much work obstructed', 'security', 'data loss', 'sudden death'. > difficulty (e.g., easy, medium, hard, expert), This is hard to classify with confidence, IMO. It also means different things: You could associate it with the set of developers qualified to handle it, or with the amount of time it would take an experienced developer to deal with it. These points of view are correlated, but I wouldn't be surprised if they have different effects on the workflow. > type goes away, I'm leaning to this myself, except that I think it is useful to inform non-developers that some things are organizationally hard. Eg, a "big RFE" will require a PEP, while a "big bug" just gets fixed ASAP. > and priority changes to be release-based (e.g., RFE since those can > occur whenever, next minor release, next micro release, > immediately, etc.). What you're talking about here is what a lot of projects call milestones. However, priority is a separate notion, especially for features. It indicates which features scheduled for the next milestone are most likely to get delayed to a later one. > I think priority should more be tied to our release cycles than this > generic notion of importance. If it is important, we should try to get > it done by a certain release. Let's have that fact directly reflected > by the tracker. Sure. Note that if you take everything I said literally and implement it, you get an unwieldy mess. Something's gotta go, I expect. But I think there are aspects to the "dream schema" you present that are not going to work as well as you would hope. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] #! magic
On Mon, Jan 21, 2008 at 12:17:20AM +0200, Tristan Seligmann wrote: > * Oleg Broytmann <[EMAIL PROTECTED]> [2008-01-20 20:12:38 +0300]: > > > On Sun, Jan 20, 2008 at 06:00:31PM +0100, Christian Heimes wrote: > > > #!/usr/bin/env python -E -s > > > >On most Unicies #! magic may have only one parameter after the program; > > the program here is env, the parameter is python, and that's all. Adding > > python options will result in different errors - some platforms silently > > ignores the options, some reports an error, some tries to find "python -E > > -s" > > in the PATH and report "Bad command or file name". > > Distro tools shouldn't be using /usr/bin/env in any case. Does > > #!/usr/bin/python -E -s > > work? No: Unknown option: - usage: /usr/bin/python [option] ... [-c cmd | -m mod | file | -] [arg] ... Try `python -h' for more information. -Es together work. I think this is why Unix has the tradition of combining options. PS. My python doesn't understand -s, so I tested a different options, but the result is the same. There are Unix variants that understand many options (I believe FreeBSD allows them) but most allow no more than one parameter in #!. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] #! magic (was PEP: per user site-packages directory)
Tristan Seligmann schrieb: > * Oleg Broytmann <[EMAIL PROTECTED]> [2008-01-20 20:12:38 +0300]: > >> On Sun, Jan 20, 2008 at 06:00:31PM +0100, Christian Heimes wrote: >> > #!/usr/bin/env python -E -s >> >>On most Unicies #! magic may have only one parameter after the program; >> the program here is env, the parameter is python, and that's all. Adding >> python options will result in different errors - some platforms silently >> ignores the options, some reports an error, some tries to find "python -E -s" >> in the PATH and report "Bad command or file name". > > Distro tools shouldn't be using /usr/bin/env in any case. Does > > #!/usr/bin/python -E -s > > work? No, but #!/usr/bin/python -Es would. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bug Day outcome
On Sun, Jan 20, 2008 at 11:23:38AM +0100, Quentin Gallet-Gilles wrote: > Excellent ! When will be the next one ? :-) We could certainly try to hold one in February. Maybe on the 16th? For March the best date is probably the Monday of the sprints at PyCon, because there will be a Python core sprint going. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PyCon 2008 Registration Open!
I am pleased to announce that PyCon 2008 registration is now open! http://us.pycon.org/2008/registration/ Early-bird registration is open until February 20, so there's one month to register at the low rates. Regular on-line registration will be available from February 21 through March 7. PyCon 2008 will be held from March 13 through 20 in Chicago: * Tutorials: Thursday, March 13 * Conference: Friday, March 14, through Sunday, March 16 * Sprints: Monday, March 17 through Thursday, March 20 Register early, especially if you'd like to attend a tutorial or three, as tutorials fill up early. And yes, you heard that correctly -- this year, we have three tutorial sessions: morning, afternoon, and evening. There are 29 great tutorials to choose from. More about the tutorials soon, but for now, you can check out the descriptions yourself here: http://us.pycon.org/2008/tutorials/schedule/ The talk schedule is also up (in a preliminary form), although some changes are expected: http://us.pycon.org/2008/conference/schedule/ Hotel reservations are also open: https://www.cteusa.com/pycon1/ The rate is $99/night plus tax ($112/night net), also until February 20. More hotel information is here: http://us.pycon.org/2008/registration/hotel/ See the PyCon web site for complete details: http://us.pycon.org/2008/ Thanks to the PyCon organizers for developing the software, providing the website content, testing & debugging. PyCon is a community conference, of, by, and for the Python community. There is still much to do, and you can help! http://us.pycon.org/2008/helping/ See you in Chicago! David Goodger PyCon 2008 Chair signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rational approximation methods
What would be useful is a method that generates (i.e., a generator in the Python sense) the (continued fraction) convergents to a rational. People wanting specific constraints on a rational approximation (including, but not limited to, the two you identified) can easily build them on top of such a generator. By "useful" I don't mean lots of people will use it ;-) I mean /some/ people will use it -- a way to generate the sequence of convergents is a fundamental tool that can be used for all sorts of stuff, by those with advanced applications. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Monkeypatching idioms -- elegant or ugly?
>I think that despite the objection that monkeypatching shoudn't be >made too easy, it's worth at looking into a unification of the API, >features, and implementation. I agree. The other virtue of having it in the standard library is that it's immediately recognisable for what it is. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
