Re: [Python-Dev] PEP: per user site-packages directory
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. I'm not sure how to solve the problem on Windows. IMHO the feature should be enabled on Windows at least but I like to keep it enabled on all systems. The PEP doesn't add a new attack vector. The problem also exist with PYTHONPATH. Paranoid programs should start with -E -s anyway and paranoid system administrators can switch a flag in site.py: # Enable per user site-packages directory # set it to False to disable the feature or True to force the feature ENABLE_USER_SITE = None If we disable the feature by default it won't be available for a lot of users. > For security reasons we also need it disabled when the getuid() != geteuid() > to avoid user supplied code being executed as another user. Defaulting to > disabled would mean that security could be left up to the end user to mess > up. (many systems do not allow setuid #! scripts but this issue would still > apply to things run under sudo) It sounds like a reasonable and easy implementable idea, at least on Unix. Windows doesn't have getuid() and geteuid(). On the other hand Windows doesn't have the suid bit, too. I also tried to check if os.stat(__main__.__file__).st_uid == os.getuid() but the real __main__ is not available in site.py. It's loaded and assigned much later. Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] complaints..
I'm sure you've heard most/all of this before but..it..just..seems..so..true...
Finally this week I've "written" (ported from sh) a bunch of Perl, 2000 sparse
lines.
While it sure beats Perl, it has some glaring flaws, more glaring due to
its overall goodness.
I feel compelled to voice my opinion, as if we don't live in a benevolent
dictatorship :),
and as if the weight of existing code was zero.
Much of what I dislike cannot be changed without massive breakage.
Below is what i get from:
jbook:/dev2/cm3/scripts/python/flaws jay$ ls -l
total 72
-rw-r--r-- 1 jay admin 834 Dec 29 16:02 1_not_lexically_scoped.py
-rw-r--r-- 1 jay admin 238 Dec 29 16:02 2_reads_scoped_writes_not.py
-rw-r--r-- 1 jay admin 593 Dec 29 16:02 3_lambda_is_neutered.py
-rw-r--r-- 1 jay admin 377 Dec 29 16:03 4_assignment_is_not_expression.py
-rw-r--r-- 1 jay admin 760 Dec 29 16:02 5_for_loop_off_by_one.py
-rw-r--r-- 1 jay admin 412 Dec 29 16:01 6_docs_good_but_a_complaint.txt
-rw-r--r-- 1 jay admin 254 Dec 29 16:02 7_print_is_wierd.py
-rw-r--r-- 1 jay admin 286 Dec 29 16:06 8_eval_vs_exec.py
-rw-r--r-- 1 jay admin 824 Dec 29 16:14 9_typo_on_read_error_but_write_ok.py
jbook:/dev2/cm3/scripts/python/flaws jay$ cat * > all.txt
jbook:/dev2/cm3/scripts/python/flaws jay$ edit all.txt
Each "---" seperates a file and they are executable Python.
- Jay
#--
# flaw #1
# not lexically scopied
# Functions have their own locals, but other blocks do not.
# This is true both for "normal" variables and lexically nested functions.
#
#
# This is probably largely an outcome of not declaring variables?
#
A = "A1:global"
def F1():
A = "A1:in first F1"
print "F1:global"
if True:
A = "A1:in if"
def F1():
A = "A1:in if.F1" # This does the right thing.
print "F1:in if"
F1() # This does the right thing.
# This should go to "global" but it goes to "in if"
F1()
def F2():
A = "A1:in F2"
def F1():
A = "A1:in F2.F1"
print "F1:in F2"
# Given how if behaved, you'd expect this to go to F2.F1 but it does not.
F1()
# This should be "global" but is "in if".
print("A is " + A)
#--
# flaw #2
#
# In functions, reads are scoped. Writes are not.
#
A = "1"
def F1():
A = "2" # not an error
def F2():
#B = A # error
A = "3"
F1()
F2()
print(A)
#--
# flaw #3:
# lambda is neutered
# It allows just one expression, and no statements
#
# This should work:
import os
#os.path.walk(
#"..",
#lambda(a, b, c):
#print(b)
#print(b)
#None)
# Instead I must say:
def Callback(a, b, c):
print(b)
print(b)
os.path.walk(
"..",
Callback,
None)
#
# Moving callbacks away from their point of use hurts readability.
# This is probably mitigated by lexical scoping of functions, but
# notice that other blocks are not lexically scoped.
#
#--
# flaw #4:
# assignment is not an expression
#
# This should work (seen in Perl code, nice idiom):
#A = [1,2]
#while (B = A.pop()):
#print(B)
# instead I must say:
A = [1,2]
while (A):
B = A.pop()
print(B)
# Even if you reject popping an empty list, ok
# there are PLENTY of applications of this.
#--
# flaw #5
#
# for loops suck
#
# It should be easy to iterate from 0 to n, not 0 to n - 1,
# thereby knowing why the loop terminated
#
#This should work:
# print the first even number, if there are any
A = [1, 3]
for i in range(0, len(A)):
if ((A[i] % 2) == 0):
print("even number found")
break;
if (i == len(A)):
print("no even numbers found")
# instead I must write:
i = 0
while (i != len(A)):
if ((A[i] % 2) == 0):
print("even number found")
break;
i += 1
if (i == len(A)):
print("no even numbers found")
# with the attendent problem of not being able to "continue" ever, since
# the end of the loop body must be run in order to proceed
Flaw #6
The docs are very good.
However the reference doesn't give much in the way
of semantic description.
It is surprising that an experienced programmer MUST
depend on the tutorial or any examples or semantics.
Light on examples, ok for reference.
The language reference is little more than the grammar in parts.
There needs to be links from the reference back to the tutorial.
Perhaps merge the indices for Tutorial, Language Reference, Library Reference.
Or maybe that's what search is for.
On the other hand, way better than Perl.
#--
# Flaw #7
#
# This is a compatibility issue.
# print is both a statement and a function, or something.
#
print() # should print just a newline, but prints two parens
# workaround:
print("")
#--
[Python-Dev] Extend reST spec to allow automatic recognition of identifiers in comments?
This is a VERY VERY rough draft of a PEP. The idea is that there should be
some formal way that reST parsers can differentiate (in docstrings) between
variable/function names and identical English words, within comments.
PEP: XXX
Title: Catching unmarked identifiers in docstrings
Version: 0.0.0.0.1
Last-Modified: 23-Aug-2007
Author: Jameson Quinn
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 23-Aug-2007
Post-History: 30-Aug-2002
Abstract
This PEP makes explicit some additional ways to parse docstrings and
comments
for python identifiers. These are intended to be implementable on their own
or
as extensions to reST, and to make as many existing docstrings
as possible usable by tools that change the visible
representation of identifiers, such as translating (non-english) code
editors
or visual programming environments. Docstrings in widely-used modules are
encouraged to use \`explicit backquotes\` to mark identifiers which are not
caught by these cases.
THIS IS AN EARLY DRAFT OF THIS PEP FOR DISCUSSION PURPOSES ONLY. ALL LOGIC
IS
INTENTIONALLY DEFINED ONLY BY EXAMPLES AND THERE IS NO REFERENCE
IMPLEMENTATION
UNTIL A THERE ARE AT LEAST GLIMMERINGS OF CONSENSUS ON THE RULE SET.
Rationale
=
Python, like most computer languages, is based on English. This can
represent a hurdle to those who do not speak English. Work is underway
on Bityi_, a code viewer/editor which translates code to another language
on load and save. Among the many design issues in Bityi is that of
identifiers in docstrings. A view which translates the identifiers in
code, but leaves the untranslated identifier in the docstrings, makes
the docstrings worse than useless, even if the programmer has a
rudimentary grasp of English. Yet if all identifiers in docstrings are
translated, there is the problem of overtranslation in either direction.
It is necessary to distinguish between the variable named "variable",
which should be translated, and the comment that something is "highly
variable", which should not.
.. _Bityi: http://wiki.laptop.org/go/Bityi
Note that this is just one use-case; syntax coloring and docstring
hyperlinks are another one. This PEP is not the place for a discussion of
all the pros
and cons of a translating viewer.
PEP 287 standardizes reST as an optional way to markup docstrings.
This includes the possibility of using \`backquotes\` to flag Python
identifiers. However, as this PEP is purely optional, there are many
cases of identifiers in docstrings which are not flagged as such.
Moreover, many of these unflagged cases could be caught programatically.
This would reduce the task of making a module internationally-viewable,
or hyperlinkable, considerably.
This syntax is kept relatively open to allow for reuse with
other programming languages.
Common cases of identifiers in docstrings
=
The most common case is that of lists of argument or
method names. We call these "identifier lists"::
def register(func, *targs, **kargs):
"""register a function to be executed someday
func - function to be called
targs - optional arguments to pass
kargs - optional keyword arguments to pass
"""
#func, targs, and kargs would be recognized as identifiers in the
above.
class MyClass(object):
"""Just a silly demonstration, with some methods:
thisword : is a class method and you can call
it - it may even return a value.
As with reST, the associated text can have
several paragraphs.
BUT - you can't nest this construct, so BUT isn't counted.
anothermethod: is another method.
eventhis -- is counted as a method.
anynumber --- of dashes are allowed in this syntax
But consider: two words are NOT counted as an identifier.
things(that,look,like,functions): are functions (see below)
Also, the docstring may have explanatory text, below or by
itself: so we have to deal with that.
Thus, any paragraph which is NOT preceded by an empty line
or another identifier list - like "itself" above - does not count
as an identifier.
"""
#thisword, anothermethod, eventhis, anynumber, and things would be
#recognized as identifiers in the above.
Another case is things which look like functions, lists, indexes, or
dicts::
"""
afunction(is,a,word,with,parentheses)
[a,list,is,a,bunch,of,words,in,brackets]
anindex[is, like, a, cross, between, the, above]
{adict:is,just:words,in:curly, brackets: likethis}
"""
#all of the above would be recogniszed as identifiers.
The "syntax" of what goes inside these is very loose.
identifier_list ::= []
{ }
, with no whitespace after initial_word, and where separator_symbol is the
set of symbols ".,<>{}[]+-*^%=|/()[]{}" MINUS closing_symbol. content_word
could maybe be a quoted string, too.
In the "function name", no whitespace
is allowe
Re: [Python-Dev] Contributing to Python
how about that py 2.5.2 release. anybody? =D On Jan 3, 2008 2:05 PM, Bill Janssen <[EMAIL PROTECTED]> wrote: > > > 3.x fixes, because there's no schedule for 2.6. > > > > Eh? PEP 3000 has a schedule that includes 2.6: > > OK, no schedule that I knew about :-). I'll get back to work on it. > > Bill > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/arashf%40mit.edu > -- Arash Ferdowsi CTO, Dropbox 913.707.5875 (m) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backport threading.py fix to 2.5.2?
On Jan 4, 2008 2:46 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > See http://bugs.python.org/issue1731. Should we consider it safe to > backport r57216 to 2.5.2? This is Thomas Wouters's code to disable > spurious tracebacks when daemon threads die. We're running some 2.4 > apps with (a variant of) this at Google that get many 1000s of > invocations a day, so I'm pretty confident that it works. > I'm also pretty confident it works, although it isn't really guaranteed to catch *all* such situations. No reason not to backport it, just a remark about how it checks to see if Python is shutting down. It is, however, incredibly unlikely '_sys' won't be gone when we check for it if the exception is indeed a spurious one. What could happen is that a legitimate exception happens right before interpreter shutdown, then a thread switch occurs before Python tries to report the exception, the interpreter exits, and then the daemonic thread starts to report its exception. The only way to catch that is to do the 'are we exiting' check in the C code that does the actual thread-exception reporting. I'm not sure if it's worth it, as the timing has to be pretty exact for that to happen, and you wouldn't want to introduce a bug there; could be years before someone figures it out :P -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] complaints..
Jay schrieb:
Only addressing the easier points here:
> #--
> # flaw #2
> #
> # In functions, reads are scoped. Writes are not.
> #
>
> A = "1"
>
> def F1():
> A = "2" # not an error
>
> def F2():
> #B = A # error
> A = "3"
>
> F1()
> F2()
> print(A)
"Writes" creates a new local. If you want to modify the enclosing
binding, the new "nonlocal" statement in 2.6/3.0 will enable that.
> #--
> # flaw #3:
> # lambda is neutered
> # It allows just one expression, and no statements
Lambda can't be altered to allow statements *and* have a consistent
indentation-based syntax.
> #--
> # flaw #5
> #
> # for loops suck
> #
> # It should be easy to iterate from 0 to n, not 0 to n - 1,
> # thereby knowing why the loop terminated
> #
>
> #This should work:
>
> # print the first even number, if there are any
>
> A = [1, 3]
> for i in range(0, len(A)):
> if ((A[i] % 2) == 0):
> print("even number found")
> break;
> if (i == len(A)):
> print("no even numbers found")
The for loop has an else clause.
for x in A:
if x % 2 == 0:
print "even number found"
break
else:
print "no even numbers found"
> Flaw #6
>
> The docs are very good.
>
> However the reference doesn't give much in the way
> of semantic description.
>
> It is surprising that an experienced programmer MUST
> depend on the tutorial or any examples or semantics.
> Light on examples, ok for reference.
>
> The language reference is little more than the grammar in parts.
>
> There needs to be links from the reference back to the tutorial.
>
> Perhaps merge the indices for Tutorial, Language Reference, Library
> Reference.
> Or maybe that's what search is for.
Look at the new docs for 2.6 -- there's many more references in it.
http://docs.python.org/dev
> #--
> # Flaw #7
> #
> # This is a compatibility issue.
> # print is both a statement and a function, or something..
> #
>
> print() # should print just a newline, but prints two parens
>
> # workaround:
>
> print("")
print is a statement, and no function. () is an empty tuple, so
"print ()" prints an empty tuple.
(""), on the other hand, is the same as "".
> #--
> # flaw #8
> #
> # Having to eval expressions but exec statements feels wrong.
> # There should just be eval.
> #
>
> # eval("print(1)") # error
> exec("print(1)") # not an error
>
> exec("1 + 2") # not an error?
> eval("1 + 2") # not an error
There's a clear distinction between expressions and statements,
so it makes sense here too.
cheers,
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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Some tardy mailman checking
The previous four posts were dredged out of the holding pen in Mailman. Sorry for the delay. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] complaints..
It would make more sense to redirect "criticism" out of beginners'
ignorance to comp.lang.python rather than spend time discussing their
misunderstandings here.
On Jan 13, 2008 9:28 AM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Jay schrieb:
>
> Only addressing the easier points here:
>
> > #--
> > # flaw #2
> > #
> > # In functions, reads are scoped. Writes are not.
> > #
> >
> > A = "1"
> >
> > def F1():
> > A = "2" # not an error
> >
> > def F2():
> > #B = A # error
> > A = "3"
> >
> > F1()
> > F2()
> > print(A)
>
> "Writes" creates a new local. If you want to modify the enclosing
> binding, the new "nonlocal" statement in 2.6/3.0 will enable that.
>
> > #--
> > # flaw #3:
> > # lambda is neutered
> > # It allows just one expression, and no statements
>
> Lambda can't be altered to allow statements *and* have a consistent
> indentation-based syntax.
>
> > #--
> > # flaw #5
> > #
> > # for loops suck
> > #
> > # It should be easy to iterate from 0 to n, not 0 to n - 1,
> > # thereby knowing why the loop terminated
> > #
> >
> > #This should work:
> >
> > # print the first even number, if there are any
> >
> > A = [1, 3]
> > for i in range(0, len(A)):
> > if ((A[i] % 2) == 0):
> > print("even number found")
> > break;
> > if (i == len(A)):
> > print("no even numbers found")
>
> The for loop has an else clause.
>
> for x in A:
> if x % 2 == 0:
> print "even number found"
> break
> else:
> print "no even numbers found"
>
> > Flaw #6
> >
> > The docs are very good.
> >
> > However the reference doesn't give much in the way
> > of semantic description.
> >
> > It is surprising that an experienced programmer MUST
> > depend on the tutorial or any examples or semantics.
> > Light on examples, ok for reference.
> >
> > The language reference is little more than the grammar in parts.
> >
> > There needs to be links from the reference back to the tutorial.
> >
> > Perhaps merge the indices for Tutorial, Language Reference, Library
> > Reference.
> > Or maybe that's what search is for.
>
> Look at the new docs for 2.6 -- there's many more references in it.
> http://docs.python.org/dev
>
> > #--
> > # Flaw #7
> > #
> > # This is a compatibility issue.
> > # print is both a statement and a function, or something..
> > #
> >
> > print() # should print just a newline, but prints two parens
> >
> > # workaround:
> >
> > print("")
>
> print is a statement, and no function. () is an empty tuple, so
> "print ()" prints an empty tuple.
> (""), on the other hand, is the same as "".
>
> > #--
> > # flaw #8
> > #
> > # Having to eval expressions but exec statements feels wrong.
> > # There should just be eval.
> > #
> >
> > # eval("print(1)") # error
> > exec("print(1)") # not an error
> >
> > exec("1 + 2") # not an error?
> > eval("1 + 2") # not an error
>
> There's a clear distinction between expressions and statements,
> so it makes sense here too.
>
> cheers,
> 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
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: per user site-packages directory
On 1/13/08, Christian Heimes <[EMAIL PROTECTED]> wrote: > > 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. > > I'm not sure how to solve the problem on Windows. IMHO the feature > should be enabled on Windows at least but I like to keep it enabled on > all systems. The PEP doesn't add a new attack vector. The problem also > exist with PYTHONPATH. Paranoid programs should start with -E -s anyway > and paranoid system administrators can switch a flag in site.py: Good point, leave it on by default. # Enable per user site-packages directory > # set it to False to disable the feature or True to force the feature > ENABLE_USER_SITE = None > > If we disable the feature by default it won't be available for a lot of > users. > > > For security reasons we also need it disabled when the getuid() != > geteuid() > > to avoid user supplied code being executed as another user. Defaulting > to > > disabled would mean that security could be left up to the end user to > mess > > up. (many systems do not allow setuid #! scripts but this issue would > still > > apply to things run under sudo) > > It sounds like a reasonable and easy implementable idea, at least on > Unix. Windows doesn't have getuid() and geteuid(). On the other hand > Windows doesn't have the suid bit, too. > > I also tried to check if os.stat(__main__.__file__).st_uid == > os.getuid() but the real __main__ is not available in site.py. It's > loaded and assigned much later. Is sys.argv[0] available at that point? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: per user site-packages directory
Gregory P. Smith wrote: >> I also tried to check if os.stat(__main__.__file__).st_uid == >> os.getuid() but the real __main__ is not available in site.py. It's >> loaded and assigned much later. > > Is sys.argv[0] available at that point? No, it's not available, too. The 'site' module is imported by Py_Initialize(). sys.argv and the real __main__ module are set much later in Modules/main.c. Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PySequence_Concat for dicts
On Jan 12, 2008, at 5:32 PM, Raymond Hettinger wrote: > Not natural, just inefficient and cute. Also, there was no answer > to the question about use cases. Fair enough. I will present some use cases below. > AFAICT, this feature has never been requested. The closest was a > feature request for a > variant of update() that avoided overwrites when a duplicate > key was encountered -- Guido rejected that one a long time ago. What about the patch I initially presented (and which you originally dealt with)? http://mail.python.org/pipermail/patches/2004-March/014323.html It seems the original request just never discussed the issue of duplicate keys (for some odd reason). > Your previous note suggests that there are alternative interpretations > of what the syntax could mean and that's not good a good thing. > That sort of ambiguity damages the language. It is not even > clear where the appropriate operators would be +-* or the > set operators &|^-. How about we keep sets for set operations and > dict for mapping operations and not foolishly conflate the two > just because we can. The mapping API is central to the language. > Altering it should be approached with a great deal of care. It was foolish of me to make those comments, you're right, and I should have known better. Guido has made it clear that the correct interpretation is that the keys of a dict form a set, which gets rid of any ambiguity. The set operators are most appropriate, though I am not exactly clear on whether this is already going to be implemented in a future version of Python, or if its just that noone will object if it appears in a future version. If it is the latter, I would still like to take a stab at implementing this as a first contribution. Would you please advise? > Also, the argument that we used + for lists so now we have > to do it for dicts is a weak one -- they are completely different > animals. > Operators are not the solution to all problems. In this case, we > don't even have a problem to be solved; there is just an urge > to hypergeneralize what was done for other datatypes where > it was appropriate. The .update() method we have now is explicit, > clear about its intent, and efficient. I agree operators are not the solution to all problems (need they be the solution to any?). My argument about + for lists was merely based on the precedent it established for sometimes sacrificing efficiency for clarity. Sometimes you may not want to alter the original lists (just as sometimes you may not want to alter the original dicts), but even when it does not matter if you do, you might still write: def prepend_with_a_b(list_a): return ['a', 'b'] + list_a instead of def prepend_with_a_b(list_a): list_b = ['a', 'b'] list_b.extend(list_a) return list_b Even though I suspect the latter will often be more efficient. The | operation for dict will not do anything that you could not otherwise do with update. I suspect most usage will be to simplify code as above. As for use cases when you actually want a new dict, I am guessing you do not want to know specifically why I don't want to alter dicts, but a more general use case, in which event the most generalized example is any case where you simply do not want to modify the original dicts. Since it seems that you might not actually need convincing that having the 4 set operations supported would be a reasonable thing to do, I will stop here for now. > IMO, the only thing this proposal has going for it is that it is cute. I suppose I should be glad for that? I might have thought you to put that to its discredit. Anyhow, I am not sure if we are now in agreement or not, but if so would you please advise on how to proceed? jared ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rounding Decimals
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. :) -- Namasté, Jeffrey Yasskin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: per user site-packages directory
I've uploaded a new patch: http://bugs.python.org/issue1799 Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rounding Decimals
On Jan 13, 2008 3:41 PM, Leif Walsh <[EMAIL PROTECTED]> wrote:
> 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?
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 :). 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.
[ A new thread is probably appropriate if anyone wants to discuss the
philosophy, but I probably won't participate... ]
--
Namasté,
Jeffrey Yasskin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] r59947 - in python/trunk:Lib/test/test_structseq.py Misc/NEWS
[Christian Heimes] > Log: > Added new an better structseq representation. E.g. repr(time.gmtime(0)) now > returns 'time.struct_time(tm_year=1970, tm_mon=1, > tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=3, tm_yday=1, tm_isdst=0)' > instead of '(1970, 1, 1, 0, 0, 0, 3, 1, 0)'. The > feature is part of #1816: sys.flags FWIW, I was looking into something similar but didn't proceed because it would break eval(repr(s)) == s as the constructor signature wants all the args in a tuple and won't accept keywords. Still, I think what you did is a nice improvement. Here's a couple more if you want to proceed down that path: 1. Have structseq subclass from PyTupleObject so that isinstance(s, tuple) returns True. This makes the object usable whenever tuples are needed. 2. Add _fields, _asdict, and _replace to match the API in collections.namedtuple(). The _fields tuple should only include the visible positional fields while _asdict() and _replace() should include all of the fields whether visible or accessible only by attribute access. Thanks for the nice work. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r59947 - in python/trunk:Lib/test/test_structseq.py Misc/NEWS
On Jan 13, 2008 7:53 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [Christian Heimes] > > Log: > > Added new an better structseq representation. E.g. repr(time.gmtime(0)) now > > returns 'time.struct_time(tm_year=1970, tm_mon=1, > > tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=3, tm_yday=1, > > tm_isdst=0)' instead of '(1970, 1, 1, 0, 0, 0, 3, 1, 0)'. The > > feature is part of #1816: sys.flags > > FWIW, I was looking into something similar but didn't proceed because it > would break eval(repr(s)) == s as the constructor signature > wants all the args in a tuple and won't accept keywords. Still, I think what > you did is a nice improvement. > > Here's a couple more if you want to proceed down that path: > > 1. Have structseq subclass from PyTupleObject so that isinstance(s, tuple) > returns True. This makes the object usable whenever > tuples are needed. Hmm, is that really necessary? structseq has been in use for quite a while and this need hasn't come up -- it's been designed to be quite compatible with tuple *except* for isinstance checks, and that has worked well. > 2. Add _fields, _asdict, and _replace to match the API in > collections.namedtuple(). The _fields tuple should only include the > visible positional fields while _asdict() and _replace() should include all > of the fields whether visible or accessible only by > attribute access. > > Thanks for the nice work. > > > Raymond > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r59947 - in python/trunk:Lib/test/test_structseq.py Misc/NEWS
Raymond Hettinger wrote: > FWIW, I was looking into something similar but didn't proceed because it > would break eval(repr(s)) == s as the constructor signature > wants all the args in a tuple and won't accept keywords. Still, I think what > you did is a nice improvement. I agree that eval(repr(s)) == s is nice to have but most complex object don't support it. In this very case the readability of the repr() is more important than eval(repr(s)). I'm sure lots of users still think that os.stat or time.time() return an ordinary tuple. I've turned your request into an issue: http://bugs.python.org/issue1820 It's a feasible yet challenging task for a new CPython coder. Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r59947 - in python/trunk:Lib/test/test_structseq.py Misc/NEWS
>> 1. Have structseq subclass from PyTupleObject so that isinstance(s, tuple) >> returns True. This makes the object usable whenever >> tuples are needed. > > Hmm, is that really necessary? structseq has been in use for quite a > while and this need hasn't come up -- it's been designed to be quite > compatible with tuple *except* for isinstance checks, and that has > worked well. It looks like that is the only difference, so subclassing from tuple won't cause any other behavioral changes. It looks like making it a subtype involves only changing a few lines. I think it can only help, especially if we start to use structseq for more things in the future. Also, I would like the API to match collections.namedtuple() as closely as possible so that there is just a single useful concept that gets applied whereever needed. The idea is basically that they *are* tuples with the added nicity of attribute access and a self-documenting repr. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r59947 - in python/trunk:Lib/test/test_structseq.py Misc/NEWS
> Hmm, is that really necessary? structseq has been in use for quite a > while and this need hasn't come up -- it's been designed to be quite > compatible with tuple *except* for isinstance checks, and that has > worked well. In addition, I would like to suggest that the current structseq usage is changed to regular classes (perhaps with slots) in Python 3. structseq was a compatibility mechanism for existing code that assumes the things returned are tuples, when they are really objects with named fields. So for struct stat and struct tm in particular, I think the indexed access should be removed in Python 3. Whether then structseq needs to be preserved at all, I don't know. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
