Re: [Python-Dev] Wow!
On Fri, Feb 13, 2009 at 9:14 PM, Greg Ewing wrote: > Also it sounds like they could do with a really good > garbage collection algorithm just now. If only we had a second Earth to mess with, we could just copy and swap. -- 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] lifting of prohibition against readlines inside a "for line in file" in Py3?
On Wed, Feb 18, 2009 at 12:42 PM, Mitchell L Model wrote: > I'd appreciate comments -- especially a redirection to a different list, if > this one isn't appropriate for my query. It seems as though you have the right list, but perhaps whoever knows about the change is busy, or maybe several people that don't know about the change are trying to find it. If there's something in particular that you need answered in a specific timeframe, I don't know what to tell you, but if it's like it seems, and you're just raising the issue, I think you can trust that someone will get to it eventually. -- 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] A suggestion: Do proto-PEPs in Google Docs
On Thu, Feb 19, 2009 at 10:17 PM, Stephen J. Turnbull wrote: > Overall, I recommend use of Google Docs for "Python-Ideas" level of > PEP drafts. +1! I also like Google Sites for collaborative editing. -- 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] svn (403 Forbidden)
On Wed, Mar 4, 2009 at 8:18 AM, Luis Saavedra wrote: > how to fix this problem?, on another machine I don't have this problem..., Which machines does it work/fail on? I probably can't help you, but maybe that will help someone else figure it out. -- 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] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
On Wed, Mar 4, 2009 at 7:53 AM, wrote: > I actually like StableDict best. When I hear that I think, "ah, the > key order is stable in the face of insertions, unlike a regular dict". > Nor can I at the moment think of an alternative explanation of what a > "StableDict" might be. +1 -- 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] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
On Wed, Mar 4, 2009 at 7:53 AM, wrote:
> I actually like StableDict best. When I hear that I think, "ah, the
> key order is stable in the face of insertions, unlike a regular dict".
> Nor can I at the moment think of an alternative explanation of what a
> "StableDict" might be.
Hmm, perhaps a better explanation than a hasty +1:
"stabledict" makes me think of merge sort, being a stable sort. In
the same way that merge sort doesn't needlessly swap elements while
sorting, stabledict might be thought to not "needlessly" swap elements
while {inserting, deleting}. I also can't think of an alternative
explanation, so thus far, it's resistant to false positive semantics.
--
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] wait time [was: Ext4 data loss]
On Thu, 2009-03-12 at 20:25 +, Antoine Pitrou wrote: > I disagree. The user usually does not know which kind of flushing is needed in > order for his data to be safe. Actually, he probably doesn't even know what > flushing means, and that files are ever "closed". > > However, I also think that any parameter to flush() or close() is a bad idea, > since it can't be used when flushing and closing is implicit. For example when > the file is used in a "with" statement. Perhaps this is an argument that the "synciness" of a file should be defined when it is opened? This doesn't give very much control to the programmer, but it certainly seems easy to use correctly. -- Cheers, Leif signature.asc Description: This is a digitally signed message part ___ 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] Getting values stored inside sets
On Fri, Apr 3, 2009 at 8:07 AM, Hrvoje Niksic wrote: > But I can't seem to find a way to retrieve the element corresponding to > 'foo', at least not without iterating over the entire set. Is this an > oversight or an intentional feature? Or am I just missing an obvious way to > do this? >>> query_obj in s True >>> s_prime = s.copy() >>> s_prime.discard(query_obj) >>> x = s.difference(s_prime).pop() Pretty ugly, but I think it only uses a shallow copy, and it might be a bit better than iterating, if difference is intelligent. I haven't run any tests though. -- 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] Rounding Decimals
On Jan 13, 2008 6:12 PM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote: > On Jan 12, 2008 8:21 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > > > On Jan 12, 2008 5:09 PM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote: > > > During the discussion about the new Rational implementation > > > (http://bugs.python.org/issue1682), Guido and Raymond decided that > > > Decimal should not implement the new Real ABC from PEP 3141. So I've > > > closed http://bugs.python.org/issue1623 and won't be pursuing any of > > > the extra rounding methods mentioned on this thread. > > > > Well, I didn't really decide anything. I suggested that if the > > developers of Decimal preferred it, it might be better if Decimal did > > not implement the Real ABC, and Raymond said he indeed preferred it. > > > > Since this reduces the usefulness of numeric.Real, I'm somewhat > > disappointed in this outcome (as I imagine you are). However, Decimal > > has very little of my own sweat in it, and a lot of Raymond, Facundo > > (and others, including Mark), and the ABC thing is still somewhat > > experimental, so it wouldn't make sense for me to impose my ideas onto > > Decimal unilaterally, and I'm sure Raymond etc. have their reasons. > > Sorry for misrepresenting you. I am a little disappointed, but if > we're right that numbers.Real is a good idea, then users will ask for > Decimal to implement it, and the Decimal developers can change their > minds in 3.1. Since I'm not one of those users, I'm not the right > person to argue for this anyway. :) I haven't been watching the python-dev list for very long, so maybe this has already been discussed ad nauseam (in which case, sorry), but, from the devil's advocate-ish mathematics side of things, unless numbers.Decimal is planned to be implemented with infinite precision (which I doubt, but could not confirm with an admittedly small amount of research), shouldn't it implement numbers.Rational instead? Was this ever discussed, or was it just assumed that numbers.Real was the right decision? 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] Rounding Decimals
On Jan 13, 2008 7:26 PM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
> Guido mentioned the possibility briefly at
> http://mail.python.org/pipermail/python-3000/2007-April/007015.html
> ("One could argue that float and Decimal are <:Q, but I'm not sure if
> that makes things better pragmatically") but never really discussed as
> far as I can find (although I did think about it :).
Well, if nothing else, I'm certainly satisfied that my concerns about
accuracy are being addressed. I will have to go read more of that
discussion.
> I prefer having
> float not implement Rational (Decimal's off the table) because
> developers usually think of them as approximations to arbitrary,
> possibly-irrational, real numbers, rather than as rational numbers
> with some odd constraints on their denominators. That is, to me, the
> ABCs a type implements are more about how developers should think
> about the type than the implementation of the type.
I see where you're coming from. My personal stance is that developers
_shouldn't_ think that way, but I know that's an unpopular opinion,
and isn't really worth discussion here.
> [ A new thread is probably appropriate if anyone wants to discuss the
> philosophy, but I probably won't participate... ]
I don't feel any pressing need to continue this here and now.
Thanks!
--
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] PEP: per user site-packages directory
On Jan 14, 2008 6:41 PM, Jon Ribbens <[EMAIL PROTECTED]> wrote: > It makes sense, but personally I have never heard before of ~/.local. > Whereas ~/bin is something I am quite familiar with. *raises hand* I have one, fwiw. -- 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] 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] trunc()
On Jan 25, 2008 12:45 PM, Facundo Batista <[EMAIL PROTECTED]> wrote: > Mmm... no. int() is a builtin way to transform the builtin data type > float into the builtin data type float [sic]. > > There's no "correct" way for a float to become an integer, but in the > math module you have several ways to do it (floor, ceil, round, trunc, > choose the one that you want, but you're "notified" that > there're different ways to do it). In keeping with this theme, why not define int() for floats (and other real types) as def __int__(n, method=math.trunc) or something similar, so that, by default, int() provides the same functionality as before (or whatever is decided to be preferred, I'm making no judgements on that end), but has a way --- by passing a different function --- of changing the way it rounds? The other (probably preferred) option, I suppose, would be to provide a few constants (float.FLOOR_METHOD et al.) instead of passing an arbitrary function (which, of course, makes me a bit uncomfortable). -- 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] getpass and stdin
On Sun, Feb 24, 2008 at 1:02 PM, Shaya Potter <[EMAIL PROTECTED]> wrote:
> [please cc me on responses]
>
> I was wondering if getpass could be changed to enable piped stdin to work.
>
> For instance, the getmail program can read my email password in via
> stdin using getpass functionality.
>
> However, if I do
>
> echo password | getmail4
>
> it will fail due to stdin not being a terminal and therefore not being
> able to do a old = termios.tcgetattr(fd) on it.
>
> From what I can tell, the point of this is to only to prevent echoing
> the password, which isn't a problem in the echo case I give (especially
> if using bash, then it wont even be on the cmdline when run from a
> script as it's a builtin, script can also read in the password and store
> it in memory).
>
> currently the code is
>
> -
> def unix_getpass(prompt='Password: '):
> """Prompt for a password, with echo turned off.
>
> Restore terminal settings at end.
> """
>
> try:
> fd = sys.stdin.fileno()
> except:
> return default_getpass(prompt)
>
> old = termios.tcgetattr(fd) # a copy to save
> new = old[:]
>
> new[3] = new[3] & ~termios.ECHO # 3 == 'lflags'
> try:
> termios.tcsetattr(fd, termios.TCSADRAIN, new)
> passwd = _raw_input(prompt)
> finally:
> termios.tcsetattr(fd, termios.TCSADRAIN, old)
>
> sys.stdout.write('\n')
> return passwd
> -
>
> it would seem that if the tcgetattr() line is moved into the initial
> try, my echo case would work as expected (as it would fail, but be
> caught and then just run default_getpass() (which should just read it
> from stdin).
>
> Is there any reason not to do it this way?
It's certainly possible to have getpass() read from stdin
automatically, but it's traditionally understood that having it read
from a tty is much, much better. Suppose your program were meant to
use getpass, and then read a file from stdin. Now, all of a sudden,
you miss the first line of the file, and it becomes your password, for
no particular reason. getpass() works the way it does because it's
been working that way in C for decades.
If you really want to maintain a 'configuration file' for your
password, or have it available on command line, try adding an option
like -p or -p to whatever program you're writing.
--
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] getpass and stdin
On Tue, Feb 26, 2008 at 12:43 PM, Shaya Potter <[EMAIL PROTECTED]> wrote: > the -p option is not good on multi user systems > the -p option is not particularly good on NFS based systems > (have to trust every user on every machine with access to NFS share) You seem somehow both worried about security, yet too lazy to type in your password. I think at some point, one of those concerns is going to have to give. > and now, assuming what you say is part of the design behind the code > > what's the point of this part of the code > > > >> try: > >> fd = sys.stdin.fileno() > >> except: > >> return default_getpass(prompt) > >> > > i.e. the exception handler, default_getpass() is always going to read > from stdin at the end of the day. > > line = sys.stdin.readline() > > I'm assuming I'm missing something Sorry, I only know my way around the libc version of getpass(), not the python one. In that version, typically we try to open /dev/tty for reading, and if that fails, we fall back to stdin. I presume that's what's going on here, but the first line appears to be getting stdin anyway, so I'm no longer sure. That said, why don't you just use default_getpass() in your code, if it reads from stdin to begin with? -- 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] getpass and stdin
On Tue, Feb 26, 2008 at 1:18 PM, Shaya Potter <[EMAIL PROTECTED]> wrote: > I want to run a program within a bash script, essentially daemonize a > program that doesn't have a daemon mode. > > #!/bin/sh > > echo "What Is Your Passsword: " > stty_orig=`stty -g` > stty -echo > read -r PASSWORD > stty $stty_orig > > TIMEOUT=600 > > while [ 1 ] > do > echo $PASSWORD | program So...why won't `program -p $PASSWORD' work here? > sleep $TIMEOUT > done -- 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] [OT] Re: getpass and stdin
On Tue, Feb 26, 2008 at 2:14 PM, Shaya Potter <[EMAIL PROTECTED]> wrote: > 1) I am willing to type in the password, which is obvious to anyone who > can read a simple script. That just doesn't work for a program you want > to run in the background to type it in every time. I recommend you just hack on this getmail program and give it a daemon mode. That shouldn't be too large of a task, and it will certainly be more secure (and you can even commit your changes as a new feature!). Otherwise, your best bet is probably, as Charles said, making the passfile work for you (maybe play with nfs and see if you can get it to hide things...I'm no wizard with it, but I'm willing to bet it's possible). > INTERNET DRAMA Let's just not continue this, shall we? -- 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] unittest's redundant assertions: asserts vs. failIf/Unlesses
On Wed, Mar 19, 2008 at 7:05 PM, Paul Moore <[EMAIL PROTECTED]> wrote: > > This strikes me as a gratuitous API change of the kind Guido was > > warning about in his recent post: "Don't change your APIs incompatibly > > when porting to Py3k" > > This seems compelling to me. And as Glyph mentioned, the testing APIs > are the most critical ones to keep working when moving from 2 to 3. It seems as though this declaration, in this case, is in direct conflict with the overarching theme of "one obvious way to do things". That statement, of course, is the reason so many things are being changed in the move to 3k already, and I don't see why this shouldn't be one of them (particularly, because it's so easy to account for this in 2to3). As one is a global statement, and the other is fairly local, I vote for the change. -- 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] [Python-3000] Invitation to try out open source code review tool
On Thu, 1 May 2008, Neal Becker wrote: > It would be really nice to see support for some other backends, such as Hg > or bzr (which are both written in python), in addition to svn. /me starts the clamour for git -- 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] PEP 8: Discourage named lambdas?
On Sat, 3 May 2008, Brett Cannon wrote: > On Sat, May 3, 2008 at 1:03 AM, Terry Reedy <[EMAIL PROTECTED]> wrote: > > Some people write > > somename = lambda args: expression > > instead of the more obvious (to most people) and, dare I say, standard > > def somename(args): return expression > > > > The difference in the result (the only one I know of) is that the code and > > function objects get the generic name '' instead of the more > > informative (in repr() output or tracebacks) 'somename'. I consider this a > > disadvantage. > > > > In the absence of any compensating advantages (other than the trivial > > saving of 3 chars), I consider the def form to be the proper Python style > > to the point I think it should be at least recommended for the stdlib in > > the Programming Recommendations section of PEP 8. > > > > There are currently uses of named lambdas at least in urllib2. This to me > > is a bad example for new Python programmers. > > > > What do our style mavens think? > > +1. A superfluous +1 from me too, although I will mention that lists of lambdas have saved my butt more than a few times. -- 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] Addition of "pyprocessing" module to standard lib.
On Mon, 19 May 2008, Bill Janssen wrote: > > On Mon, May 19, 2008 at 5:15 PM, Bill Janssen <[EMAIL PROTECTED]> wrote: > > >> If you can run a pure Python module > > >> that does not depend on any C extension, then that platform has the > > >> support needed to run Python. > > > > > > This is certainly a point of view. One that many end-users wouldn't > > > understand :-). > > > > Perhaps, but it's clear-cut. Is OS X not properly supported because it > > can't run the _winreg module? I just don't like labeling a platform as > > unsupported just because ctypes doesn't compile on it. > > I assume _winreg runs everywhere Python is said to run, and there's a > Windows registry to examine, so I think it's a different kettle of > fish. ctypes doesn't run everywhere Python is said to run, and there > are dynamic libraries to call into. > > I think it would be great if we could get some AIX, HP-UX, and Solaris > boxes for Thomas to work on. What would motivate IBM, H-P, and Sun to > donate such gear? Perhaps each of the companies have an office > somewhere that could help with this resource allocation? For > instance, talking to the "AIX Collaboration Center" of IBM > ([EMAIL PROTECTED])? > > And these are all SYSV derivatives, aren't they? So perhaps it's some > common fix for all three? I just spent a semester in "Advanced Systems Programming in Unix/C", and all we did was port old software to solaris, hpux, irix, and friends (I don't think we used AIX, but I believe he has one running). Most of these were virtual machines, but they adequately represented the annoyances present in their respective architectures. I've cc'd my professor, hopefully he will let me know if there are any tips he has for setting up a VM. -- 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] Possible bug in re module?
On Tue, 20 May 2008, Dmitry Vasiliev wrote:
> I've just found a strange re behavior:
>
> >>> import re
> >>> re.sub("(?:ab|b|a)", "+", "cbacbabcabc")
> 'c++c++c+c'
> >>> re.sub("(?:ab|b|a){2}", "+", "cbacbabcabc")
> 'c+c+c+c'
>
> In the last case |-separated expressions seems don't tried from left to right.
> Is it bug or just me?
What were you expecting, 'c+c+cabc'? The re engine should try
everything possible for a match with the entire re, not just match the
first thing it finds for each section.
--
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] Addition of "pyprocessing" module to standard lib.
On Thu, 22 May 2008, "Martin v. Löwis" wrote: > > I would say that writing portable C code is hard as well, aren't there > > just more tools that help? > > The C compiler in particular. It already gets symbolic constants and > struct layouts right, something that ctypes can't do (because it doesn't > use header files). I don't think it makes much sense to talk about "The C Compiler" when you are discussing matters of portability. Just my $0.02. -- 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] Assignment to None
I haven't been following this thread very closely, so I'm not sure what the status is, but I'd just like to point out that yesterday I used the fact that a[None] = b works, when I used the @memoize decorator from the wiki. This seems to provide an argument that, for symmetry's sake, we might want to keep a.None = b as well. -- 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] Assignment to None
On Thu, Jun 12, 2008 at 10:28 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > That makes about as much sense as wanting to support a.42 = b since > a[42] = b works. :-) Well don't I feel silly now. -- 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] Python FAQ: Why doesn't Python have a "with" statement?
-1 to this 'on' statement. On Sat, Jun 14, 2008 at 10:14 PM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > It isn't that a Pascal-with-style statement can't be achieved, it's that it > is pointless syntactic sugar in Python. Just use o = > long_complicated_object_name instead. +1 to this reason. -- 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] Proposal: Run GC less often
If you can get me a version of the interpreter with this change made (I wouldn't know what to change), I can run a very allocation/deallocation-heavy application I have lying around, and get you some good benchmarks. On Sat, Jun 21, 2008 at 1:23 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: - Show quoted text - > Here is my proposal for making the GC run less often. > The objective is to avoid the quadratic-time behavior > if many objects are created and none of them is garbage. > > The youngest generation remains collected after 700 > allocations, the middle generation after 10 young collections. > Therefore, full GC remains considered every 7000 allocations. > The two youngest generations don't cause quadratic behavior, > as the number of objects in each generation is bounded. > > Currently, full GC is invoked every 10 middle collections. > Under my proposal, 10 middle collections must have passed, > PLUS the number of survivor objects from the middle generation > must exceed 10% of the number of objects in the oldest > generation. > > As a consequence, garbage collection becomes less frequent > as the number of objects on the heap grows, resulting in > an amortized O(N) overhead for garbage collection (under > the access pattern stated above). > > To determine the number of survivor objects, counts are > taken during the collection. Objects deallocated through > reference counting still remain accounted for as survivors > (likewise for determining the size of the oldest generation). > > I made a simulation assuming an initially-empty heap, > and invocations of the collector every M=7000 objects. > The table below is in units of M and shows the number > of objects allocated, and the number of objects inspected > since the start of the simulation, for the old and the > new scheme (the asterisk indicates that a collection > took place; lines with no collection are dropped): > > total old_inspected new_inspected > 10 10* 10* > 20 30* 30* > 30 60* 60* > 40100*100* > 50150*150* > 60210*210* > 70280*280* > 80360*360* > 90450*450* > 100550*450 > 102550 552* > 110660*552 > 115660 667* > 120780*667 > 129780 796* > 130910*796 > 140 1050*796 > ... > 940 44650* 7724 > 942 446508666* > 950 45600* 8666 > 960 46560* 8666 > 970 47530* 8666 > 980 48510* 8666 > 990 49500* 8666 > 1000 50500* 8666 > ... > 99904995000* 95887 > > As you can see, the old and the new scheme would start > of equally until 100M objects have been allocated. The > table shows how the old scheme grows quadratically, and > the new scheme eventually approaches roughly a factor > of ten between the number of objects and the number of > times that GC considers an object. > > Applications with a small number of objects will see no > change in behavior, also, applications that create > lots of small cycles will continue to see them collected > in the youngest or middle generations. > > Please let me know what you think. > > Regards, > Martin > > P.S. I don't plan to implement this myself, so if you like > the idea, go ahead. > > ___ > 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/adlaiff6%40gmail.com > > -- 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] [Python-3000] RELEASED Python 2.6b1 and 3.0b1
There is a typo on the download page (http://python.org/download/releases/3.0/): """The release plan is to have a series of alpha releases in 2007, beta releases in 2008, and a final release in September 2008. The alpha releases are primarily aimed at developers who want a sneak peek at the new langauge, especially those folks who plan to port their code to Python 3000. The hope is that by the time of the final release, many 3rd party packages will already be available in a 3.0-compatible form. """ Should be """The release plan is to have a series of alpha releases in 2007, beta releases in 2008, and a final release in September 2008. The alpha releases are primarily aimed at developers who want a sneak peek at the new *language*, especially those folks who plan to port their code to Python 3000. The hope is that by the time of the final release, many 3rd party packages will already be available in a 3.0-compatible form. """ -- 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] [Python-3000] RELEASED Python 2.6b1 and 3.0b1
There is a typo on the download page (http://python.org/download/releases/3.0/): """The release plan is to have a series of alpha releases in 2007, beta releases in 2008, and a final release in September 2008. The alpha releases are primarily aimed at developers who want a sneak peek at the new langauge, especially those folks who plan to port their code to Python 3000. The hope is that by the time of the final release, many 3rd party packages will already be available in a 3.0-compatible form. """ Should be """The release plan is to have a series of alpha releases in 2007, beta releases in 2008, and a final release in September 2008. The alpha releases are primarily aimed at developers who want a sneak peek at the new *language*, especially those folks who plan to port their code to Python 3000. The hope is that by the time of the final release, many 3rd party packages will already be available in a 3.0-compatible form. """ (I really need to add my other e-mail address to these lists...sorry if my first message got through to one of them and this is a dupe.) -- 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] [Python-checkins] r64424 - in python/trunk: Include/object.h Lib/test/test_sys.py Misc/NEWS Objects/intobject.c Objects/longobject.c Objects/typeobject.c Python/bltinmodule.c
On Tue, 24 Jun 2008, Nick Coghlan wrote: > I'd prefer to see a proper PEP for this proposing a new slot that lets any > class return an (integer_part, fraction_part) tuple of integers, and > have PyNumber_ToBase take care of the actual string formatting. I take issue only with your notion of returning a 'fraction_part integer'. How do you propose we do this? I suggest we add a third value, exponent, to the suggested return value. -- 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] fileobj.read(float): warning or error?
On Tue, 22 Jul 2008, Cameron Simpson wrote: > Leaving aside the 0.2 => 0 converstion, shouldn't read() raise an > exception if asked for < 1 bytes? Or is there a legitimate use for > read(0) with which I was not previously aware? I think read(0) should be a no-op, just like it is in libc. This lets you write 'read(bytes)' without worrying about checking bytes, and also lets you silently stop reading when you have no more space, like in the following: buf = f.read(max(bytes_left, page_size)) while buf: process(buf) # updates bytes_left buf = f.read(max(bytes_left, page_size)) -- 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] fileobj.read(float): warning or error?
On Tue, Jul 22, 2008 at 3:46 PM, Cameron Simpson <[EMAIL PROTECTED]> wrote: > [ Don't you mean "min()"? Unimportant. ] Haha, that's what I get for not actually _running_ the code example. > I see the convenience here, but doubt I'd ever do that myself. > I'd write the above like this: > > while bytes_left > 0: >buf = f.read(max(bytes_left, page_size)) >if buf == 0: > break >process(buf) # updates bytes_left > > I'm kind of picky about doing things exactly as often as required and no > more. Especially things that call another facility. I do the same, but I know lots of people that prefer the example I sent earlier. Also, if we ever adopt the "while ... as ..." syntax (here's not hoping) currently being discussed in another thread, having read(0) return None or an empty buffer will cause that idiom to short circuit as well. > read(0) itself must internally have a check for size == 0 anyway, so > it's not like the overall system is less complex. If we're unlucky it > could trickle all the way down to an OS system call to read(2) (UNIX, > substitute as suitable elsewhere) and for a no-op that would be overkill > by far. The only way the read() implementation would avoid that is by > doing the test on size anyway. But since read() is opaque IMO it is > better to avoid it at the upper level if we know it will produce > nothing. If we are going to make read(0) a no-op, we should definitely do it before it hits the underlying implementation, for portability's sake. On Tue, Jul 22, 2008 at 4:43 PM, Victor Stinner <[EMAIL PROTECTED]> wrote: > Would it possible to create an option "strict mode" which disallow dangerous > cast? Especially in PyArg_Parse*() functions. Ack! We're not writing Perl here, guys. Can we please not start having multiple subsets of the language that are separately valid? -- 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] if-syntax for regular for-loops
On Fri, Oct 3, 2008 at 6:10 AM, Andreas Nilsson <[EMAIL PROTECTED]> wrote: > With that out of the way, on to todays subject: > I use list comprehensions and generator expressions a lot and lately I've > found myself writing a lot of code like this: > > for i in items if i.some_field == some_value: i.do_something() > > Naturally it won't work but it seems like a pretty straight-forward > extension to allow compressing simple loops to fit on one line. The > alternative, in my eyes, suggests there's something more happening than a > simple include-test which makes it harder to comprehend. > > for i in items: >if i.some_field == some_value: i.do_something() > > One possibility of course is to use a generator-expression but that makes it > look like there are two for loops and it feels like a waste setting up a > generator just for filtering. > > for i in (i for i in items if some_field == some_value): >i.do_something() > > Stupid idea? Am I missing some obviously better way of achieving the same > result? It's been discussed already. Essentially, all that saves is a newline or two, which, as I think has been generally accepted, tends to hurt readability. Here's the full discussion: http://www.mail-archive.com/python-dev@python.org/msg29276.html Other than that, welcome! -- 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] if-syntax for regular for-loops
On Fri, Oct 3, 2008 at 12:33 PM, Andreas Nilsson <[EMAIL PROTECTED]> wrote: > Thanks for the pointer! > I don't buy the argument that newlines automagically improves readability > though. You also get increased nesting suggesting something interesting is > happening where it isn't and that hurts readability. > And as Vitor said, all other constructions of the form 'for i in items' can > have if-conditions attached to them, it's really not that far-fetched to > assume that the loop behaves the same way. Consistency good, surprises bad. Yeah, I know what you mean, and I kind of liked the idea of adding the if statement to the for loop (for consistency, if nothing else), but it's been discussed before, and plenty of people have made the same argument. Probably not worth it. -- 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] Fwd: Removal of GIL through refcounting removal.
On Thu, Oct 30, 2008 at 1:07 PM, VanL <[EMAIL PROTECTED]> wrote: > Just an FYI, these two particular students already introduced themselves > on the PyPy list. Paolo is a masters student with experience in the > Linux kernel; Sigurd is a PhD candidate. > > Their professor is Lars Bak, the lead architect of the Google V8 > Javascript engine. They spent some time working on V8 in the last couple > months. This just gives me really high expectations. Go get 'em! -- 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] Why don't range and xrange threat floats as floats?
On Wed, Nov 5, 2008 at 1:26 PM, L V <[EMAIL PROTECTED]> wrote: > Why don't range and xrange threat floats as floats? > Is there any good reason range and xrange don't threat floats as floats but > as integers? > When I enter float arguments in a range, the floats are treated as integers. > (+ some warning) > > This is how I think it should work: range(0, 1, 0.1) > [0.0, 0.10001, 0.20001, 0.2, > 0.40002, 0.5, 0.59998, 0.69996, > 0.80004, 0.90002] > > I got these results by: [x/10. for x in xrange(10)] > > I'm not looking for alternatives, just for the reason that it works this > way. This seems like a question to be asked on python-list, not python-dev. In any case, my best guess is that it's because of what you just showed, that the functionality you want is there already if you use a generator expression. There isn't much reason to make (x)range more complicated by letting it accept floats, when you can just scale the range you actually want up to some integral skip value, call range, and then scale it back down. -- 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] DVCS PEP update
On Thu, Nov 6, 2008 at 8:04 AM, Dirkjan Ochtman <[EMAIL PROTECTED]> wrote: > I can represent Mercurial, though it may be (more?) helpful if some of the > Mercurial-using python-dev regulars can occasionally step in. I like mercurial, so I'll do this if I see something, but I don't use it for anything that heavy-duty, so I don't expect to be able to say anything very convincing, or, I suppose, intelligent. -- 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] Feedback from numerical/math community on PEP 225
On Fri, Nov 7, 2008 at 11:01 PM, Fernando Perez <[EMAIL PROTECTED]> wrote: > a while back there was a discussion about new operators for the language, > which > ended in people mentioning that the status of PEP 225 was still undecided and > that it was the most likely route to consider in this discussion. I offered > to collect some feedback from the numerical and math/scientific computing > communities and report back here. I've only used a bit of numpy, but I have to say, the ~*/etc. syntax looks extremely ugly. There doesn't really seem to be a solution to this that isn't ugly in some way, but the op(a, b) version looks best to me (I also think a.op(b) is out of the question). -- 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] Python for windows.
This list is for the development of python. Questions about programming with python go to c.l.python or python-list at python dot org. If your question is about the development of python, you can probably just ask here. On Wed, Nov 26, 2008 at 2:06 PM, Koenig, Gerald <[EMAIL PROTECTED]> wrote: > Hi all, > > I am working For Hewlett-Packard designing PC Consumer Desktop > > We have been including Python since over 10 years now on our systems. > > It is a wonderful language and very powerful. > > Now I am having a small issue and I was wondering how I can solve it. > > So I would like to know who should I contact to be able to work on that issue > together ? > > The issue is about some requirement I need to have on our systems and even > tools need to pass those requirement. > > Regards > > Gerald Koenig > Software Builds Architect > Hewlett-Packard > Work Phone: +(1) 408 873 6202 > > ___ > 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/leif.walsh%40gmail.com > -- 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] extremely slow exit for program having huge (45G) dict (python 2.5.2)
On Sat, Dec 20, 2008 at 3:04 PM, M.-A. Lemburg wrote: > These long exit times are usually caused by the garbage collection > of objects. This can be a very time consuming task. In that case, the question would be "why is the interpreter collecting garbage when it knows we're trying to exit anyway?". -- 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] extremely slow exit for program having huge (45G) dict (python 2.5.2)
(@Skip, Michael, Tim) On Sat, Dec 20, 2008 at 3:26 PM, wrote: > Because useful side effects are sometimes performed as a result of this > activity (flushing disk buffers, closing database connections, etc). Of course they are. But what about the case given above: On Sat, Dec 20, 2008 at 5:55 AM, Steven D'Aprano wrote: > I was originally one of the skeptics until I reproduced the original > posters problem. I generated a sample file 8 million key/value pairs as > a 370MB text file. Reading it into a dict took two and a half minutes > on my relatively slow computer. But deleting the dict took more than 30 > minutes even with garbage collection switched off. It might be a semantic change that I'm looking for here, but it seems to me that if you turn off the garbage collector, you should be able to expect that either it also won't run on exit, or it should have a way of letting you tell it not to run on exit. If I'm running without a garbage collector, that assumes I'm at least cocky enough to think I know when I'm done with my objects, so I should know to delete the objects that have __del__ functions I care about before I exit. Well, maybe; I'm sure one of you could drag out a programmer that would make that mistake, but turning off the garbage collector to me seems to send the experience message, at least a little. Does the garbage collector run any differently when the process is exiting? It seems that it wouldn't need to do anything more that run through all objects in the heap and delete them, which doesn't require anything fancy, and should be able to sort by address to aid with caching. If it's already this fast, then I guess it really is the sheer number of function calls necessary that are causing such a slowdown in the cases we've seen, but I find this hard to believe. -- 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] extremely slow exit for program having huge (45G) dict (python 2.5.2)
On Sat, Dec 20, 2008 at 4:11 PM, Tim Peters wrote: > [Lots of answers] Thanks. Wish I could have offered something useful. -- 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] python.org OS
I missed the beginning here; oh well. On Sun, Jan 4, 2009 at 9:51 AM, Aahz wrote: > On Sun, Jan 04, 2009, Stephen J. Turnbull wrote: >> Steve Holden writes: >>> >>> Hey, isn't Ubuntu Debian-based? ... >> >> Ouch. I don't actually use Ubuntu, but when everybody on my local LUG >> list from the "Linux should be Windows but cheaper" newbies to former >> NetBSD developers is grouching about upgrade hell, I don't see any >> real benefits to be gained. You're still going to need to go with a >> "don't think about fixing what ain't broke, and even if it's just >> kinda broke, Just Say No to that upgrade dope" policy. In my experience, Ubuntu tends to stray away from the Way Things Are Traditionally Done, and this can be problematic, sometimes. Because they change things so drastically, they can do some pretty neat stuff, but if I decide I want to tweak something on my own, I usually find that they haven't provided a mechanism for changing something they've already changed (or at least not for a few releases). So, I blunder on ahead and mess with it, and when it comes time to upgrade, their scripts are expecting it to be the way they left it, but obviously it isn't that way, so it breaks horribly. Of course, if you aren't trying to mess with all manner of weird things (I think my latest trouble came from messing with pam and shared memory to get my audio software to run smoothly), it should be perfectly stable and upgradable. -- 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] How to configure with icc on Mac?
On Sun, Jan 4, 2009 at 12:05 PM, wrote: > Hmmm, OK... Why do we need two ways to spell "don't use gcc"? Think of it like the two keys to the atom bomb. :-P -- 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] python.org OS
On Sun, Jan 4, 2009 at 8:51 PM, Steve Holden wrote:
> Ubuntu is a victim of its own success. They now have to deal with the
> same diversity of hardware environments as Windows. I hope that
> Canonical will find a way to stabilize things.
I think it's actually worse. Microsoft can always (and, in my
experience, often does) restrict their support to hardware sets
approved for "Windows ver. N". Custom-built or upgraded
("tampered-with") boxes often get worse (or no) support than OEM
boxes. Linux distributions, on the other hand, are expected to
provide support for any hardware. In this respect, since Ubuntu has a
larger user base, and therefore a larger range of hardware sets, yes,
their job is difficult, but I'm not sure this is a victimization,
rather more of an inherent issue exacerbated by its success. Either
way, it does kind of suck.
On Sun, Jan 4, 2009 at 11:26 PM, Stephen J. Turnbull wrote:
> This certainly conforms to what I've seen on that LUG list. Since
> nobody on that list is running Ubuntu server, the "scary one" (quoted
> above) can probably be discounted, too. That looks like some
> user-friendliness run amok.
True, most of the upgrade problems deal with packages that aren't in
the server install. This should be an easy one, but now I'd ask, why
not use Debian instead?
--
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] Partial function application 'from the right'
On Thu, Jan 29, 2009 at 9:12 AM, Ben North wrote:
> I find 'functools.partial' useful, but occasionally I'm unable to use it
> because it lacks a 'from the right' version. E.g., to create a function
> which splits a string on commas, you can't say
First of all, many functions like this are easy to handle yourself. Example:
>>> def split_comma(s):
>>> return str.split(s, ',')
That said, it seems to me that if we're going to add to
functools.partial, we should go all the way and allow keyword
arguments (or a dict of them, if it's otherwise too hard to
implement). Otherwise, in another few {days, weeks, months} we'll see
another thread like this clamoring for a keyword-sensitive
functools.partial.
Come to think of it, I would imagine the next iteration would ask for
a way to curry arbitrary positional arguments, and I can't come up
with a simple and beautiful way to do that off the top of my head.
Maybe this is an argument for keeping functools.partial the way it is
and forcing developers to write their own currying functions.
--
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] Partial function application 'from the right'
On Fri, Jan 30, 2009 at 7:38 PM, Calvin Spealman wrote: > I am just replying to the end of this thread to throw in a reminder > about my partial.skip patch, which allows the following usage: > > split_one = partial(str.split, partial.skip, 1) > > Not looking to say "mine is better", but if the idea is being given > merit, I like the skipping arguments method better than just the > "right partial", which I think is confusing combined with keyword and > optional arguments. And, this patch already exists. Could it be > re-evaluated? +1 but I don't know where the patch is. -- 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
