Re: [Python-Dev] Wow!
On Tue, 17 Feb 2009 11:04:35 +1300, Greg Ewing wrote: > Leif Walsh wrote: > >> If only we had a second Earth to mess with, we could just copy and >> swap. > > Or we could use a generational approach, doing all our messy stuff > around the moon and copying to earth when we've got our traffic control > issues sorted out. Oh great, people not only trashed on the ground, but also the space. Have you never seen the garbage bin sign? Wait a minute... the standard lib must have something about this... import walle ___ 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] IO implementation: in C and Python?
On Thu, 19 Feb 2009 21:41:51 -0600, Benjamin Peterson wrote: > As we prepare to merge the io-c branch, the question has come up [1] > about the original Python implementation. Should it just be deleted in > favor C version? The wish to maintain the two implementations together > has been raised on the basis that Python is easier to experiment on and > read (for other vm implementors). > > Thoughts? > > http://bugs.python.org/issue4565 How about making it an optional module instead, a compile flag when compiling python would determine whether the python or C or both versions of the libraries would be included with C-only as the default. Alternatively, if the compile flag was turned off and you want access to the python version, provide a downloadable pure python library (OS package manager could have something like python-lib-purepy or something similar). This would streamline python, and only people who want to mess around would download the purepy version. ___ 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] Challenge: Please break this! [Now with blog post]
On Mon, 23 Feb 2009 23:22:19 +, tav wrote: > Steve, this isn't death by a 1,000 cuts. What's being put forward here > is not a specific implementation -- but rather a specific model of > security (the object capability model) -- which has been proven to be > foolproof. Proven? Isn't it impossible to prove something like this? "Nobody ever see an alien" is not a proof for "There is no alien". "Nobody have thought of a way to break the model" is not a proof for "The model is invincible"... ___ 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
Gisle Aas wrote:
On Mar 4, 2009, at 9:01 , Glenn Linderman wrote:
On approximately 3/3/2009 11:22 PM, came the following characters from
the keyboard of Raymond Hettinger:
Perhaps the terminology should be
ordereddict -- what we have here
sorteddict -- hypothetical future type that keeps
itself sorted in key order
+1
-1
Introducing the hypothetical sorteddict would serve to reduce the
likelihood of ordereddict being interpreted as sorteddict among the
small percentage of people that actually read the two lines that might
mention it in the documentation, but wouldn't significantly aid the
intuition of people who first encounter it in someone else's code.
And without an implementation, it would otherwise be documentation
noise, not signal.
Instead of introducing a sorteddict I would instead suggest that the
future should bring an odict with a sort method; possibly also
keys_sorted and items_sorted methods.
I think this would simplify things and putting these methods into the
odict documentation makes it clearer how it actually behaves for people
that just scan the method index to get an impression of what the object
is about.
How about making odict ordered by insertion order, then provide an
optional argument for defining sorter? This optional argument must be a
function/lambda/callable object and must be the first argument.
a = odict(bloh='foo', blah='faa')
a # odict([('bloh', 'foo'), ('blah', 'faa')])
b = odict(lambda a, b: (a[0] < b[0]), bloh='foo', blah='faa')
b # sorted by key: odict([('blah', 'faa'), ('bloh', 'foo')])
c = odict(lambda a, b: (a[1] < b[1]), bloh='foo', blah='faa')
c # sorted by value: odict([('blah', 'faa'), ('bloh', 'foo')])
b = odict(lambda a, b: (a[0] > b[0]), bloh='foo', blah='faa')
b # sorted by key, descending: odict([('bloh', 'foo'), ('blah', 'faa')])
___
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
Steve Holden wrote: Raymond Hettinger wrote: Perhaps the terminology should be ordereddict -- what we have here sorteddict -- hypothetical future type that keeps itself sorted in key order +1 FIFOdict ? Yeah, that blows the capitalization scheme, way, way out. Issues: * The popitem() method is LIFO. * In a non-popping context, there is no OUT. It just stores. * FIFO is more suggestive of queue behavior which does not apply here. * Stores to existing keys don't go at the end; they leave the order unchanged. FWIW, PEP 372 has links to seven other independent implementations and they all have names that are some variant spelling OrderedDict except for one which goes by the mysterious name of StableDict. Am still +1 on painting the class green with pink polka dots, but I'm starting to appreciate why others are insisting on pink with green polka dots ;-) historydict? agedict? ___ 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
Nick Coghlan wrote: Lie Ryan wrote: How about making odict ordered by insertion order, then provide an optional argument for defining sorter? This optional argument must be a function/lambda/callable object and must be the first argument. or better yet, in the spirit of dumping cmp comparison like in list, the first optional argument would be a function that returns the sorting key of the object. If the optional argument is not specified, the current ordereddict semantic (by insertion order) will be used. As the PEP mentions (and Hrvoje brought up again already in this thread), a hash table (i.e. dict) probably isn't the right data structure to use as the basis for an "always sorted" container. In-memory databases, balanced trees, etc, etc. Isn't ordered dictionary essentially also an "always sorted" container? It is always sorted depending on the order of insertion? I can't see any technical reason why the data structure can't accommodate them both. Can you point me to a discussion on this? ___ 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
Steven D'Aprano wrote: I also can't think of an alternative explanation, so thus far, it's resistant to false positive semantics. "The keys don't expire with time." "It's stable against accidental deletions." "It's stable against accidentally over-writing values." Add to that: "The StableDict is stable because it has no bugs, unlike the buggy dict" ___ 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
Terry Reedy wrote:
Lie Ryan wrote:
Isn't ordered dictionary essentially also an "always sorted"
container? It is always sorted depending on the order of insertion? I
can't see any technical reason why the data structure can't
accommodate them both. Can you point me to a discussion on this?
Appending an item at the end of a sequence is O(1), no search required.
Inserting an item at a random 'sorted' point requires at best an
O(logN) search. Insertion itself is O(1) to O(N) depending on the
structure.
Yeah, but with a proper algorithm[1] it is possible to get a O(1) append
(which is the characteristic we want for insertion order dictionary,
while falling back to O(log n) if we explicitly give comparer function
(or comparison key extractor).
[1] The insertion algorithm will test for where to insert from the end
of the list. This way, insertion-order dict will still be O(1) (with an
increased constant), else if custom order is specified insertion it will
be O(n)
#UNTESTED BECAUSE I DON'T HAVE PYTHON CURRENTLY
# Note that it derives from OrderDict
class MyOrderDict(OrderDict):
def __init__(*args, **kwds):
if len(args) > 2:
raise TypeError('expected at most 2 arguments')
if len(args) == 2:
self._cmp, args = args[0], args[1:]
else:
self._cmp = lambda a, b: True
if not hasattr(self, '_keys'):
self._keys = []
self.update(*args, **kwds)
def __setitem__(self, key, value):
if key not in self:
self._key.append(None)
for i, k in enumerate(reversed(self._key)):
i = -i - 1
if self._cmp((k, self[k]), (key, value)):
self._key[i], self._key[i - 1] = k, key
else:
self._key[i] = k
dict.__setitem__(self, key, value)
___
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 wins Linux New Media Award for Best Open Source Programming Language
Martin v. Löwis wrote: The prize was Martin von Löwis of the Python Foundation on behalf of the Python community itself. This is a funny translation from German-to-English. :-) But yeah, a good one and the prize was presented by Klaus Knopper of Knoppix. Congratulations! Actually, the prize went to "Python", not to me, and not to the PSF. So congratulations to you as well! The (translated) article says that YOU are the prize? WOW. Ummm... better not to use automatic translator for anything mission critical. ___ 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] PEP 239 - Rational
PEP 239 says that Rational type was Rejected, but some time ago this decision is reverted, and now python 3.0 and python 2.6 includes a fractions.Fraction type. Shouldn't this PEP be updated? (At least to include a note of its obsoleted status or to point to the reversion) ___ 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] Ext4 data loss
Scott Dial wrote:
Aahz wrote:
On Wed, Mar 11, 2009, Antoine Pitrou wrote:
After Hrvoje's message, let me rephrase my suggestion. Let's instead allow:
open(..., sync_on="close")
open(..., sync_on="flush")
with a default of None meaning no implicit syncs.
That looks good, though I'd prefer using named constants rather than
strings.
I would agree, but where do you put them? Since open is a built-in,
where would you suggest placing such constants (assuming we don't want
to pollute the built-in namespace)?
I actually prefer strings. Just like 'w' or 'r' in open().
Or why not add "f" "c" as modes?
open('file.txt', 'wf')
open for writing, sync on flush
___
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] Formatting mini-language suggestion
James Y Knight wrote:
On Mar 11, 2009, at 11:40 PM, Nick Coghlan wrote:
Raymond Hettinger wrote:
It is not the goal to replace locale or to accomodate every
possible convention. The goal is to make a common task easier
for many users. The current, default use of the period as a decimal
point has not proven to be problem eventhough that convention is
not universal. For a thousands separator, a comma is a decent choice
that makes it easy follow-on with s.replace(',', '_') or somesuch.
In that case, I would simplify my suggestion to:
[[fill]align][sign][#][0][minimumwidth][,][.precision][type]
Addition to mini language documentation:
The ',' option indicates that commas should be included in the
output as a thousands separator. As with locales which do not use a
period as the decimal point, locales which use a different convention
for digit separation will need to use the locale module to obtain
appropriate formatting.
This proposal has the advantage that you're not overly specifying the
behavior in the format string itself.
That is: the "," option is really just indicating "please insert
separators". With the current locale-ignorant implementation, that'd
just mean "a comma every 3 digits". But it leaves the door open for a
locale-sensitive variant of the format to be added in the future without
conflicting with the instructions in the format string. (as the ability
to specify an arbitrary character, or the ability to specify a comma
instead of a period for the decimal point would).
I'm not against Raymond's proposal, just against doing a *bad* job of
making it work in multiple locales. Locale conventions can be complex,
and are going to be best represented outside the format string.
How about having a country code field, e.g. en-us would format according
to US locale, in to India, ch to China, etc... that way the format
string would become very simple (although the lib maintainer would need
to know customs from all over the world). Then have a special country
code that is a placeholder for whatever the locale the machine is set to.
___
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] wait time [was: Ext4 data loss
Steven D'Aprano wrote: On Fri, 13 Mar 2009 01:02:26 pm R. David Murray wrote: On Fri, 13 Mar 2009 at 00:35, Antoine Pitrou wrote: R. David Murray bitdance.com> writes: Seriously, though, the point is that IMO an application should not be calling fsync unless it provides a way for that behavior to be controlled by the user. But whether an application does it or not is none of Python's business, is it? What is the disagreement exactly? I'd like to see whatever feature gets added support the application writer in making this user controllable, or at the very least document that this to do so is best practice if you use the sync feature. It's not best practice. It may be best practice for a certain class of users and applications, e.g. those who value the ability to control low-level behaviour of the app, but it is poor practice for other classes of users and applications. Do you really think that having Minefield make the file syncing behaviour of the high scores file user-configurable is best practice? People care about their high scores, but they don't care that much. It may even lead to more data loss than leaving it out: * If the application chooses a specific strategy, this strategy might (for the sake of the argument) lead to data loss once in ten million writes on average. * If the application makes this a configuration option, the increased complexity of writing the code, and the increased number of paths that need to be tested, may lead to bugs which cause data loss. This may be more risky than the original strategy above (whatever that happens to be.) Complexity is not cost-free, and insisting that the more complex, expensive solution is always "best practice" is wrong. If the pops and moms uses a financial program and lost their only copy of 10 years worth of financial data, they'll simply be confused and that's it. Meanwhile if a network administrator needs to squeeze the last bit of performance out of his backup script, he definitely would threaten the dev-team of the programming language to make manual sync file writing the default, since it makes it difficult for him to fine-tune the syncing process. ___ 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] Integrate BeautifulSoup into stdlib?
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Moore wrote: 2009/3/13 Chris Withers : If a decent package management system *was* included, this wouldn't be an issue.. Remember that a "decent package management system" needs to handle filling in all the forms and arranging approvals to get authorisation for packages when you download them. And no, I'm *not* joking. People in a locked-down corporate environment really do benefit from just having to get the OK for "Python", and then knowing that they have all they need. You are plainly joking: nothing in Python should know or care about the various bureaucratic insanities in some workplaces. Given the *existing* stdlib and network connectivity, nothing any corporate security blackshirt can do will prevent an even moderately-motivated person from executing arbitrary code downloaded from elsewhere. In that case, what is the point in trying to help those who impose such craziness? I (and most people, I presume) would not run arbitrary program downloaded from somewhere else on a corporate server that holds many important customer data even when there is no technical or even bureaucratic restriction, maybe I will sneak around on a workstation but definitely not on the server especially if I love my job and want to keep it (I'm a student though so that applies to me in the future). ___ 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] Integrate BeautifulSoup into stdlib?
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lie Ryan wrote: Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Moore wrote: 2009/3/13 Chris Withers : If a decent package management system *was* included, this wouldn't be an issue.. Remember that a "decent package management system" needs to handle filling in all the forms and arranging approvals to get authorisation for packages when you download them. And no, I'm *not* joking. People in a locked-down corporate environment really do benefit from just having to get the OK for "Python", and then knowing that they have all they need. You are plainly joking: nothing in Python should know or care about the various bureaucratic insanities in some workplaces. Given the *existing* stdlib and network connectivity, nothing any corporate security blackshirt can do will prevent an even moderately-motivated person from executing arbitrary code downloaded from elsewhere. In that case, what is the point in trying to help those who impose such craziness? I (and most people, I presume) would not run arbitrary program downloaded from somewhere else on a corporate server that holds many important customer data even when there is no technical or even bureaucratic restriction, maybe I will sneak around on a workstation but definitely not on the server especially if I love my job and want to keep it (I'm a student though so that applies to me in the future). I'm not arguing that employees should violate their employers' policies: I'm arguing that Python itself shouldn't try to cater to such policies. Basically you're saying: Python is designed not to work on such environment. Note that I'm not talking about running code pushed on me by malware authors, either: I'm talking about "ordinary" software development activities like using a script from a cookbook, or using a well-tested and supported library, rather than NIH. Some companies have /very/ strict policies on running anything on live server, including scripts you write yourself. The problem is if the script goes awry, it might disturb the stability or even security of the server. Given that the out-of-the-box Python install already has facilities for retrieving text over the net and executing that text, the notion of "locking down" a machine to include only the bits installed in the stock Python install is just "security theatre;" such a machine shouldn't have Python installed at all (nor a C compiler, etc.) When the server administrator is already freaked out about adding an script developed by in-house employee, what about adding an external module? Of course all of this does not (usually) apply to regular workstation. A messed up workstation only means a reinstall, a messed up server may mean company reputation. ___ 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] Numeric alignment issue with PEP 3101
Raymond Hettinger wrote: I concur. Numbers are naturally right aligned. Isn't numbers are "naturally right aligned" because of the Big Endian notations that most mathematicians currently use. Had we been using Little Endian notation, numbers would be naturally left-aligned, wouldn't they? And I sort of disagree with saying it's naturally left- or right- aligned; as numbers are naturally (decimal) dot-aligned (if you use dot to separate the whole and fractional part of your number). ___ 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] transitioning from % to {} formatting
Michael Foord wrote: Benjamin Peterson wrote: 2009/10/5 Nick Coghlan : So I would agree that method invocation on literals (particularly string literals) is an already established language idiom. And who hasn't ever used 4.56.as_integer_ratio()? :) > I've tried 4.__add__ a few times (not for a while now though). That's a Syntax Error >>> 4.__add__ File "", line 1 4.__add__ ^ SyntaxError: invalid syntax however this works: >>> 4 .__add__ ___ 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 patch for functools partial - Interested?
On 05/08/10 03:57, Steve Holden wrote: > Steven D'Aprano wrote: >> >> [...] >>> Similarly, if you wanted p1==p2, why not write >>> >>> p1 = partial(operator.add) >>> p2 = p1 >> >> I thought the OP gave a use-case. He's generating "jobs" (partial >> applied to a callable and arguments), and wanted to avoid duplicated >> jobs. >> >> I think it is reasonable to expect that partial(operator.add, 2) >> compares equal to partial(operator.add, 2). I don't think he's >> suggesting it should compare equal to partial(lambda x,y: x+y, 2). >> > Which absence, presumably, also mildly disappoints you? > it disappoints me this does not compare equal: add3 = lambda a, b, c: a + b + c a = partial(partial(add3, 1), 2) b = partial(partial(add3, 2), 1) print a == b :-) ___ 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] Documenting [C]Python's Internals
On 05/21/10 15:18, Yaniv Aknin wrote: > I would if I were qualified, but I an mot. One way to get people to help >> with details is to publish mistakes. This happens all the time on >> python-list ;-). Pre-review would be nice though. >> > > I don't mind so much the 'humiliation' of published mistakes, but since I > want this to be perceived as reference grade material, I prefer pre-review. > Yesterday my first mistake was found (ugh), I published an 'Errata Policy' > and will stick to it from now on (see the blog itself for details of the > mistake). Thankfully, I've been approached already about pre-review, we'll > see how this develops (this doesn't mean other people can't also offer > themselves, six eyeballs are better than four). How about a separate blog (or wiki) for alpha-quality articles? After an article is written, it is first posted to the alpha blog, and after some time and eyeballs, moved to the original blog. Of course with an open comment system, so people can easily suggest corrections. ___ 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] Floating-point implementations
On Tue, 09 Dec 2008 12:15:53 -0500, Steve Holden wrote: > Is anyone aware of any implementations that use other than 64-bit > floating-point? I'd be particularly interested in any that use greater > precision than the usual 56-bit mantissa. Do modern 64-bit systems > implement anything wider than the normal double? > > regards > Steve Why don't we create a DecimalFloat datatype which is a variable-width floating point number. Decimal is variable precision fixed-point number, while the plain ol' float would be system dependent floating point. ___ 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] Psyco for -OO or -O
I'm sure probably most of you knows about psyco[1], the optimizer. Python has an -O and -OO flag that is intended to be optimization flag, but we know that currently it doesn't do much. Why not add psyco as standard library and let -O or -OO invoke psyco? [1] http://psyco.sourceforge.net/index.html ___ 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] Psyco for -OO or -O
On Sat, 13 Dec 2008 13:28:37 +, Michael Foord wrote: > Lie Ryan wrote: >> I'm sure probably most of you knows about psyco[1], the optimizer. >> Python has an -O and -OO flag that is intended to be optimization flag, >> but we know that currently it doesn't do much. Why not add psyco as >> standard library and let -O or -OO invoke psyco? >> >> > This really belongs on Python-ideas and not Python-dev. Ah yes, sorry about that, I'm new here. This will be my last post about this here... ___ 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
