python-graph 1.8.2 released
python-graph release 1.8.2 http://code.google.com/p/python-graph/ python-graph is a library for working with graphs in Python. This software provides a suitable data structure for representing graphs and a whole set of important algorithms. The code is appropriately documented and API reference is generated automatically by epydoc. Provided features and algorithms: * Support for directed, undirected, weighted and non-weighted graphs * Support for hypergraphs * Canonical operations * XML import and export * DOT-Language output (for usage with Graphviz) * Random graph generation * Accessibility (transitive closure) * Breadth-first search * Critical path algorithm * Cut-vertex and cut-edge identification * Cycle detection * Depth-first search * Gomory-Hu cut-tree algorithm * Heuristic search (A`*` algorithm) * Identification of connected components * Maximum-flow / Minimum-cut (Edmonds-Karp algorithm) * Minimum spanning tree (Prim's algorithm) * Mutual-accessibility (strongly connected components) * Pagerank algorithm * Shortest path search (Dijkstra's algorithm) * Shortest path search (Bellman-Ford algorithm) * Topological sorting * Transitive edge identification Download: http://code.google.com/p/python-graph/downloads/list Installing: If you have easy_install on your system, you can simply run: # easy_install python-graph-core And, optionally, for Dot-Language support: # easy_install python-graph-dot -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
Re: [OT] Simulation Results Managment
moo...@yahoo.co.uk writes: ... Does pickle have any advantages over json/yaml? It can store and retrieve almost any Python object with almost no effort. Up to you whether you see it as an advantage to be able to store objects rather than (almost) pure data with a rather limited type set. Of course, pickle is a proprietary Python format. Not so easy to decode it with something else than Python. In addition, when you store objects, the retrieving application must know the classes of those objects -- and its knowledge should not be too different from how those classes looked when the objects have been stored. I like very much to work with objects (rather than with pure data). Therefore, I use pickle when I know that the storing and retrieving applications all use Python. I use pure (and restricted) data formats when non Python applications come into play. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Qt4 Designer
On 15/07/12 07:31, Michael Torrie wrote: On 07/14/2012 11:13 AM, rusi wrote: I looked at the second link and find code like this: app = None if ( not app ): app = QtGui.QApplication([]) Maybe I'm dense but whats that if doing there? Frankly I seem to be a bit jinxed with gui stuff. A few days ago someone was singing the praises of some new themed tk stuff. I could not get the first two lines -- the imports -- to work and then gave up Since you haven't had any experience with gui development then probably loading ui files isn't the right place to start. First principles (creating gui widgets from scratch) would be it. In any case, the line in question is quite simple. It creates a QApplication object, which is basically the engine that drives all Qt applications. Once you call .run() on it, it takes over and handles all the mouse events and such for you. In fact you do not have any control over the program's execution from this point on, other than to define event call-back methods or functions that are called by the widgets when things happen, like mouse clicks. All gui toolkits operate this way. You set up the widgets, then you run the main engine or main event loop and control never returns to your main program until something triggers the end (like closing a window or the quit menu item is pressed). Probably a complete working example is what you need to see, that is documented. I primarily work with Gtk, but I'll whip up a Qt one tomorrow if I can. Rusi is not the op, and his question is about these lines app = None if ( not app ): not this one app = QtGui.QApplication([]) which should be written like this app = QtGui.QApplication(sys.argv) -- Vincent V.V. Oqapy https://launchpad.net/oqapy . Qarte https://launchpad.net/qarte . PaQager https://launchpad.net/paqager -- http://mail.python.org/mailman/listinfo/python-list
Implicit conversion to boolean in if and while statements
This has probably been discussed before, but why is there an implicit
conversion to a boolean in if and while statements?
if not None:
print('hi')
prints 'hi' since bool(None) is False.
If this was discussed in a PEP, I would like a link to it. There are so
many PEPs, and I wouldn't know which ones to look through.
Converting 0 and 1 to False and True seems reasonable, but I don't see
the point in converting other arbitrary values.
--
CPython 3.3.0b1 | Windows NT 6.1.7601.17803
--
http://mail.python.org/mailman/listinfo/python-list
Re: lambda in list comprehension acting funny
On Sun, 15 Jul 2012 10:49:48 +1000, Chris Angelico wrote: On Sun, Jul 15, 2012 at 9:29 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Not necessarily *compile* time, but the distinction is between when the function is defined (which may at compile time, or it may be at run time) versus when the function is called. I'd treat the def/lambda statement as compile time and the () operator as run time. But function definitions occur at run time, not compile time -- they are executable statements, not instructions to the compiler to define a function. For example: py dis(def f(x): return x+1) # Python 3.2 1 0 LOAD_CONST 0 (code object f at 0xb7b57de0, file dis, line 1) 3 MAKE_FUNCTION0 6 STORE_NAME 0 (f) 9 LOAD_CONST 1 (None) 12 RETURN_VALUE The code object is pre-compiled at compile time, but the function and name-binding (the def) doesn't occur until runtime. At compile time, Python parses the source code and turns it into byte- code. Class and function definitions are executed at run time, the same as any other statement. I'm not sure if this is a difference that makes a difference or not; I think it is, but don't know enough about how closures and scoping rules work in other languages to be sure that it does make a difference. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: lambda in list comprehension acting funny
On Sun, Jul 15, 2012 at 6:32 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: At compile time, Python parses the source code and turns it into byte- code. Class and function definitions are executed at run time, the same as any other statement. Between the parse step and the 'def' execution, a code object is created. When you call it, that code object already exists. Nothing else really matters, unless there's a bug in the Python optimizer or something weird like that. The nearest thing Python _has_ to a compile time is the execution of def. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Implicit conversion to boolean in if and while statements
On Sun, Jul 15, 2012 at 6:34 PM, Andrew Berg bahamutzero8...@gmail.com wrote: Converting 0 and 1 to False and True seems reasonable, but I don't see the point in converting other arbitrary values. It's for convenience. Unfortunately, not all languages treat all types the same way. It's very handy, though, to be able to use if not foo: foo = some_initializer when foo starts out as, say, None. Or []. Or, in fact, any other empty value. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Implicit conversion to boolean in if and while statements
Andrew Berg, 15.07.2012 10:34: This has probably been discussed before, but why is there an implicit conversion to a boolean in if and while statements? There isn't. This has nothing to do with if or while. All objects have a truth value in Python, evaluating to True by default (object), unless they implement the test themselves. As Chris said, very convenient. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: lambda in list comprehension acting funny
On 7/15/2012 4:32 AM, Steven D'Aprano wrote: On Sun, 15 Jul 2012 10:49:48 +1000, Chris Angelico wrote: On Sun, Jul 15, 2012 at 9:29 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Not necessarily *compile* time, but the distinction is between when the function is defined (which may at compile time, or it may be at run time) versus when the function is called. I'd treat the def/lambda statement as compile time and the () operator as run time. But function definitions occur at run time, not compile time -- they are executable statements, not instructions to the compiler to define a function. The () operator is 'call time'. The main points are a) the execution of def statements and lambda expressions and the execution of calls happen at different run times. b) default arg objects are calculated at def/lambda time. c) names in def bodies and lambda expressions are resolved at call time. and d) people more often forget c) when thinking about lambda expressions that for def statements. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Implicit conversion to boolean in if and while statements
On Sun, 15 Jul 2012 03:34:46 -0500, Andrew Berg wrote:
This has probably been discussed before,
By the hoary hosts of Hoggoth, has it ever!
but why is there an implicit
conversion to a boolean in if and while statements?
It's nothing to do with if and while. All Python objects are duck-typed
as bools.
1) It's generally part of the duck-typing philosophy. If an object quacks
like a bool, why not treat it as a bool?
2) It's useful and convenient for short-circuit boolean expressions such
as any(), all(), and various things like:
for x in mylist or []:
...
is better than:
if mylist is not None:
for x in mylist:
...
3) Rather than distinguishing true from false, a more useful
dichotomy is between something and nothing. Python includes a number
of ways of spelling nothing of various types, such as:
None, 0, 0.0, '', [], {}, set()
and nearly everything else is something.
4) Other languages such as Ruby, Javascript, PHP, Clojure and others also
distinguish between true-like and false-like (truthy and falsey)
values. Although some of them have made some pretty weird and arbitrary
choices for what counts as true-like and false-like, without Python's
general principle that nothing values should be false.
(E.g. Javascript considers Boolean(false) to be a true value!!!)
5) Prior to Python 2.2, there was no bool type and no True and False
values. In fact, here is an impassioned plea from an educator begging
Guido not to introduce True and False to the language, because duck-typed
truthy/falsey values are *so much better*.
http://groups.google.com/group/comp.lang.python/msg/2de5e1c8384c0360?hl=en
Sadly, or happily, Python did grow True and False values, but the
fundamental distinction between something and nothing still exists.
(For the record, I can only think of one trap for the unwary: time
objects are false at *exactly* midnight.)
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Simulation Results Managment
Dieter Maurer wrote: moo...@yahoo.co.uk writes: ... Does pickle have any advantages over json/yaml? It can store and retrieve almost any Python object with almost no effort. Up to you whether you see it as an advantage to be able to store objects rather than (almost) pure data with a rather limited type set. Of course, pickle is a proprietary Python format. Not so easy to decode it with something else than Python. In addition, when you store objects, the retrieving application must know the classes of those objects -- and its knowledge should not be too different from how those classes looked when the objects have been stored. I like very much to work with objects (rather than with pure data). Therefore, I use pickle when I know that the storing and retrieving applications all use Python. I use pure (and restricted) data formats when non Python applications come into play. Typically what I want to do is post-process (e.g. plot) results using python scripts, so using pickle is great for that. -- http://mail.python.org/mailman/listinfo/python-list
Re: 2 + 2 = 5
On Friday, July 6, 2012 8:39:58 AM UTC+10, Andrew Cooper wrote: On 05/07/2012 22:46, Evan Driscoll wrote: gt; On 01/-10/-28163 01:59 PM, Alexander Blinne wrote: gt;gt; 5+0 is actually 4+0, because 5 == 4, so 5+0 gives 4. gt;gt; 5+1 is actually 4+1, which is 5, but 5 is again 4. gt;gt; 5+2 is 4+2 which is 6. gt; gt; Now all I can think is quot;Hoory for new math, new-hoo-hoo mathquot; :-) gt; gt; Evan It wont do you a bit of good to read new math! (My mind was on exactly the same track) ~Andrew +1 -- http://mail.python.org/mailman/listinfo/python-list
Re: Keeping the Console Open with IDLE
On Friday, February 20, 2009 9:41:42 AM UTC-6, David Smith wrote: What I meant was open open the command prompt, type cd, space, DO NOT hit enter yet. Drag the folder with your script into the command prompt window. Then go to the command prompt window and hit enter. This should compose a command similar to the following: And why the hell would you resort to such contrived contortions as that? Are you masochistic? DoubleClicking an icon will take me less that one second. How long does this sequence take: 1. Open a command prompt 2. type c 3. type d 4. type space 5. hover over the folder icon with your mouse 5.5. Oops, i missed. Go back to step 5! 6. Mouse click the file icon 7. Mouse drag the file icon 8. Position the mouse over prompt window 9. Release the icon 10. Press the Enter key Can anybody say !Ay, caramba!? Besides, you can skip most of those steps by Shift+RightClicking the file icon and choosing Open Command Window Here. But, why the hell would you EVEN do that when two simple clicks will suffice? practicality beats purity -- http://mail.python.org/mailman/listinfo/python-list
Re: Keeping the Console Open with IDLE
On Mon, Jul 16, 2012 at 1:35 AM, rantingrickjohn...@gmail.com wrote: Besides, you can skip most of those steps by Shift+RightClicking the file icon and choosing Open Command Window Here. That's not standard. Me, I can invoke git bash anywhere I want it, but that doesn't mean I'd recommend installing git just so that people can get command lines with less steps. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Keeping the Console Open with IDLE
On Sunday, July 15, 2012 10:57:00 AM UTC-5, Chris Angelico wrote: On Mon, Jul 16, 2012 at 1:35 AM, rantingrickjohn...@gmail.com wrote: Besides, you can skip most of those steps by Shift+RightClicking the file icon and choosing Open Command Window Here. That's not standard. Me, I can invoke git bash anywhere I want it, but that doesn't mean I'd recommend installing git just so that people can get command lines with less steps. I don't understand Chris? It's obvious that the OP is on a windows box; for which no installation is required. And, what is so egregious about less steps(sic)? Do you prefer to be unproductive? Did you forget the lazy programmers creed? Is your employer paying you by the hour? ...all good questions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Implicit conversion to boolean in if and while statements
On Sun, Jul 15, 2012 at 4:56 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: (For the record, I can only think of one trap for the unwary: time objects are false at *exactly* midnight.) Ugh, that's irritating. I can't think of any scenario where I would ever want the semantics if timeval (is not midnight):. This reinforces the point that if you only want to test whether you have None, you should use is not None rather than relying on __bool__. -- http://mail.python.org/mailman/listinfo/python-list
Re: Simulation Results Managment
On Jul 15, 11:35 am, Dieter Maurer die...@handshake.de wrote: moo...@yahoo.co.uk writes: ... Does pickle have any advantages over json/yaml? It can store and retrieve almost any Python object with almost no effort. Up to you whether you see it as an advantage to be able to store objects rather than (almost) pure data with a rather limited type set. Of course, pickle is a proprietary Python format. Not so easy to decode it with something else than Python. In addition, when you store objects, the retrieving application must know the classes of those objects -- and its knowledge should not be too different from how those classes looked when the objects have been stored. I like very much to work with objects (rather than with pure data). Therefore, I use pickle when I know that the storing and retrieving applications all use Python. I use pure (and restricted) data formats when non Python applications come into play. Pickle - JSON - Yaml are roughly in increasing order of human-friendliness and decreasing order of machine friendliness (where machine means python 'machine') This means that - Pickle is most efficient, Yaml least - Pickle comes with python from as far back as I know Json started coming somewhere round 2.5 (I think) (py)yaml needs to be installed separately - reading pickled data will spoil your eyes whereas yaml is pleasant to read (just like python) -- http://mail.python.org/mailman/listinfo/python-list
Re: Keeping the Console Open with IDLE
On Mon, Jul 16, 2012 at 2:19 AM, Rick Johnson rantingrickjohn...@gmail.com wrote: On Sunday, July 15, 2012 10:57:00 AM UTC-5, Chris Angelico wrote: On Mon, Jul 16, 2012 at 1:35 AM, rantingrickjohn...@gmail.com wrote: Besides, you can skip most of those steps by Shift+RightClicking the file icon and choosing Open Command Window Here. That's not standard. Me, I can invoke git bash anywhere I want it, but that doesn't mean I'd recommend installing git just so that people can get command lines with less steps. I don't understand Chris? It's obvious that the OP is on a windows box; for which no installation is required. I have here a Windows XP system (shh, it doesn't know there's Linux between it and the hardware) which has no such context-menu item. Ergo it is not standard and cannot be assumed to be on the target computer, and installation IS required. And, what is so egregious about less steps(sic)? Do you prefer to be unproductive? Did you forget the lazy programmers creed? Is your employer paying you by the hour? ...all good questions. And if you're going to quibble about fewer steps then you should probably have an apostrophe in lazy programmers' creed. Just sayin'. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Implicit conversion to boolean in if and while statements
On Sunday, July 15, 2012 11:19:16 AM UTC-5, Ian wrote: On Sun, Jul 15, 2012 at 4:56 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: (For the record, I can only think of one trap for the unwary: time objects are false at *exactly* midnight.) Ugh, that's irritating. I can't think of any scenario where I would ever want the semantics if timeval (is not midnight):. This reinforces the point that if you only want to test whether you have None, you should use is not None rather than relying on __bool__. I think this issue is not so much a bool test vs type test, but more an ambiguous syntax issue. Consider this: ## EXAMPLE A ## py if money: ... do_something() The syntax if money implies we are testing/measuring some attribute of money, but what exactly about money are we testing/measuring? The problem lies in the syntax. To understand this syntax, we must first interpret what *IF* means, and we should *NEVER* need to interpret such a well defined word as *IF*! This syntax is far too opaque. Consider the alternative: ## EXAMPLE B ## py if bool(money): ... do_something() Now we have a hint. Even if we don't understand the inner workings of the bool function, we *do* understand that the statement bool(money) *must* return True or the block *will not* execute. We must NEVER present if in such confusing manner as ExampleA. I believe Guido made a grave mistake allowing this syntax to flourish. His intentions where noble, to save people a few keystrokes, but all he accomplished was to pave a road directly into hell. Explict is better than Implict -- http://mail.python.org/mailman/listinfo/python-list
Re: Implicit conversion to boolean in if and while statements
On 7/15/2012 5:56 AM, Steven D'Aprano wrote:
3) Rather than distinguishing true from false, a more useful
dichotomy is between something and nothing. Python includes a number
of ways of spelling nothing of various types, such as:
None, 0, 0.0, '', [], {}, set()
and nearly everything else is something.
Okay, I see the value in this, but I don't understand why None has a
truth value. I would expect None to mean doesn't exist or unknown or
something like that - e.g., a value of 0 means 0 jelly beans in the jar
and None means there isn't a jar.
FWIW, I have, for a reason I forget, gotten into the habit of writing
if x is not None when testing for None. However, I have not been
writing if x is True: .../elif x is False: .../else: 'ruh-roh'
when testing for True (in cases where a value of True or False makes
sense, but any other value would not). Should I?
--
CPython 3.3.0b1 | Windows NT 6.1.7601.17803
--
http://mail.python.org/mailman/listinfo/python-list
Re: Implicit conversion to boolean in if and while statements
On 7/15/2012 11:19 AM, Ian Kelly wrote: Ugh, that's irritating. I can't think of any scenario where I would ever want the semantics if timeval (is not midnight):. It's not implemented with such a test, but logging.handlers.TimedRotatingFileHandler has an option to rollover at midnight. -- CPython 3.3.0b1 | Windows NT 6.1.7601.17803 -- http://mail.python.org/mailman/listinfo/python-list
Re: Request for useful functions on dicts
On Sat, Jul 14, 2012 at 5:56 PM, Leif leif.poor...@gmail.com wrote:
Hi, everybody. I am trying to collect all the functions I've found useful for
working with dicts into a library:
https://github.com/leifp/dictutil
If you have a favorite dict-related func / class, or know of similar
projects, please let me know (or open an issue on github). Bear in mind that
the functions don't even have to come from python; if you have a favorite PHP
/ APL / COBOL / etc associative array function, that's fair game.
Nothing in particular comes to mind, but I'll be happy to critique
what you've already got.
One thing that bothers me a bit is that get_in will accept any
iterable, but set_in and update_in can only accept a sequence in order
to do the slicing. Here's an alternate implementation for set_in that
takes any iterable:
def set_in(d, ks, v):
tmp = d
i = None
for i, next_key in enumerate(ks):
if i 0:
tmp = tmp.setdefault(current_key, {})
current_key = next_key
if i is None:
raise KeyError(Empty keys iterable)
tmp[current_key] = v
update_in could be rewritten similarly. You might also notice that
I'm not returning d here. That's because the Pythonic way is to
either create a new object and return it, or mutate the existing
object and return None. If you mutate the existing object and return
it, that can lead to confusion about which style the method takes.
This is why list.append (for example) always returns None.
In Python 2.7+, intersection and difference could be written using
dictviews, which act like sets.
partition_on_value, partition_on_key: The only difference between
these is whether it passes the key or the value to the predicate. You
could just pass both and let the predicate decide which one (or both)
to use, and then you only need a single function. Also, why a
predicate specifically? This could be generalized to partition any
equivalence relation, not just those with only two equivalence
classes:
def partition(f, d):
Partition the dict according to an equivalence relation.
Calls f(key, value) for all (key, value) pairs in the dict d. The return
value of f must be hashable.
Returns a new dict where the keys are distinct return values of f, and the
values are dicts containing the equivalence classes distinguished by those
return values.
partition = defaultdict(dict)
for k, v in d.iteritems():
partition[f(k, v)][k] = v
return partition
If you still wanted the predicate semantics, you could then define
that as a wrapper:
def partition_pred(f, d):
p = partition(lambda k,v: bool(f(k,v)), d)
return p[True], p[False]
issubdict could be implemented as a subset operation. I haven't timed
it so it may not really be any faster, but this way the looping is in
C instead of in Python:
def issubdict(d1, d2):
return set(d1.items()).issubset(d2.items())
Finally, isempty(d) is basically equivalent to not d, which is both
shorter and faster.
Cheers,
Ian
--
http://mail.python.org/mailman/listinfo/python-list
Re: Implicit conversion to boolean in if and while statements
On Sun, Jul 15, 2012 at 11:16 AM, Andrew Berg bahamutzero8...@gmail.com wrote: On 7/15/2012 11:19 AM, Ian Kelly wrote: Ugh, that's irritating. I can't think of any scenario where I would ever want the semantics if timeval (is not midnight):. It's not implemented with such a test, but logging.handlers.TimedRotatingFileHandler has an option to rollover at midnight. Nor could it be implemented with such a test, since the rollover check would then have to run at exactly midnight for the test to evaluate false. If it were off by 1 microsecond, it would miss it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Implicit conversion to boolean in if and while statements
On Sun, Jul 15, 2012 at 10:50 AM, Rick Johnson rantingrickjohn...@gmail.com wrote: I think this issue is not so much a bool test vs type test, but more an ambiguous syntax issue. Consider this: ## EXAMPLE A ## py if money: ... do_something() The syntax if money implies we are testing/measuring some attribute of money, but what exactly about money are we testing/measuring? The problem lies in the syntax. To understand this syntax, we must first interpret what *IF* means, and we should *NEVER* need to interpret such a well defined word as *IF*! This syntax is far too opaque. Consider the alternative: ## EXAMPLE B ## py if bool(money): ... do_something() Now we have a hint. Even if we don't understand the inner workings of the bool function, we *do* understand that the statement bool(money) *must* return True or the block *will not* execute. So now instead of having to understand how if handles arbitrary values, we have to understand how bool handles arbitrary values. How is that an improvement? What should if do if presented a value that isn't True or False? Raise a TypeError? Next thing we know, people get so used to wrapping everything they present to if in a bool() call, that they start writing silly things like if bool(x == 7) and if bool(isinstance(x, int)). Why? Because it's faster and easier to automatically wrap the value in bool than it is to put in the effort to verify that the value will always be a bool to begin with in order to avoid a useless and annoying exception. At the point that happens, the bool() is effectively just part of the if syntax, and we're back to where we started. -- http://mail.python.org/mailman/listinfo/python-list
Re: Initial nose experience
Hi Roy, I've been using unittest for many years, but have steadfastly (perhaps stubbornly) avoided newfangled improvements like nose. I finally decided to take a serious look at nose. Thanks for sharing your nose experience. What motivated you to migrate from unittest to nose? After years of using unittest, what would you say are the pros and cons of nose? Thank you, Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Re: Implicit conversion to boolean in if and while statements
On Sunday, July 15, 2012 1:01:58 PM UTC-5, Ian wrote: So now instead of having to understand how if handles arbitrary values, we have to understand how bool handles arbitrary values. How is that an improvement? Because we are keeping the condition consistent. We are not relying on implicit resolution of an object's value based on some dark, esoteric and inconsistent rules that defy all normal logic. What should if do if presented a value that isn't True or False? Raise a TypeError? YES! Because IT IS the author's responsibility to present a condition that evaluates to either True or False. Anything else would be ridiculously inconsistent. Next thing we know, people get so used to wrapping everything they present to if in a bool() call, that they start writing silly things like if bool(x == 7) and if bool(isinstance(x, int)). We cannot prevent morons from doing stupid things. x==7 IS an explicit statement that evaluates to either True or False. Likewise, isinstance(obj, type) is a function that evaluates to either True or False. Wrapping either example in a bool call is redundant and only obfuscates the meaning. True equals True and False equal False. Why do you need to test that truth? The only time you will be forced to use the bool is when you are NOT using rich comparisons or NOT using truth testing functions in a condition. The following require NO bool function: obj == obj - bool obj != obj - bool obj obj - bool obj obj - bool obj = obj - bool obj = obj - bool isinstance(obj, type) - bool callable(obj) - bool hasattr(obj, name) - bool issubclass(obj, name) - bool ..along with any function that returns a bool Whereas: if obj - Some esoteric semantics that defies all logic! Why? Because it's faster and easier to automatically wrap the value in bool than it is to put in the effort to verify that the value will always be a bool to begin with in order to avoid a useless and annoying exception. No, because we want our code to be EXPLICIT and consistent! Remember, writing obfuscated code is easy, however, interpreting obfuscated code is difficult! A good measure of your programming skill is to see how easily your code is read by the majority. If it's difficult to explain, it's probably a bad idea. if blah is difficult to explain, whereas if bool(blah) is not. At the point that happens, the bool() is effectively just part of the if syntax, and we're back to where we started. That's a ridiculous conclusion. See points above^^^ -- http://mail.python.org/mailman/listinfo/python-list
Re: Initial nose experience
In article mailman.2149.1342375358.4697.python-l...@python.org, pyt...@bdurham.com wrote: Hi Roy, I've been using unittest for many years, but have steadfastly (perhaps stubbornly) avoided newfangled improvements like nose. I finally decided to take a serious look at nose. Thanks for sharing your nose experience. What motivated you to migrate from unittest to nose? Mostly I was just looking for a better way to run our existing tests. We've got a bunch of tests written in standard unittest, but no good way to start at the top of the tree and run them all with a single command. -- http://mail.python.org/mailman/listinfo/python-list
Re: lambda in list comprehension acting funny
On 15/07/12 10:44:09, Chris Angelico wrote: On Sun, Jul 15, 2012 at 6:32 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: At compile time, Python parses the source code and turns it into byte- code. Class and function definitions are executed at run time, the same as any other statement. Between the parse step and the 'def' execution, a code object is created. When you call it, that code object already exists. Nothing else really matters, unless there's a bug in the Python optimizer or something weird like that. The nearest thing Python _has_ to a compile time is the execution of def. ChrisA Compile time is the phase when your Python code is turned into byte code, or a SyntaxError is raised. In this phase, a code object is created for the function. Function definition time is when the def command is executed. In this phase, default arguments are computed, and a function object is created. Among the attributes of the function object are the code object, and cell objects containing the bindings for its non-local variables. These bindings are used to read the variable's current value at the time the function uses the variable. -- HansM -- http://mail.python.org/mailman/listinfo/python-list
Re: Request for useful functions on dicts
Thanks for the suggestions, Ian! I implemented most of them and pushed the code. That#39;s because the Pythonic way is to either create a new object and return it, or mutate the existing object and return None. You're saying what I was already thinking. In Python 2.7+, intersection and difference could be written using dictviews, which act like sets. I'm debating with myself right now whether to support 2.5 and 2.6. def partition(f, d): Good idea, thanks. issubdict could be implemented as a subset operation. I haven#39;t timed The current implementation is a bit faster, and it's quite a bit faster on the common (for me) case, where one argument is much smaller than the other. I wrote it that way because if m=len(first), n=len(second), the amount of work is O(min(m,n)). Your implementation is O(m + n). Not really a big deal, unless e.g. m n. --Leif -- http://mail.python.org/mailman/listinfo/python-list
Re: Implicit conversion to boolean in if and while statements
On 7/15/2012 12:19 PM, Ian Kelly wrote: On Sun, Jul 15, 2012 at 4:56 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: (For the record, I can only think of one trap for the unwary: time objects are false at *exactly* midnight.) Ugh, that's irritating. I can't think of any scenario where I would ever want the semantics if timeval (is not midnight):. This When printing time tables, midnight may be either 24:00 or 0:00, depending on whether it is the end or start of a journey. That could, of course, be done by explicit if time == midnight: rather than if not time:. Whether to change the current behavior was discussed on python-ideas a couple of months ago. I believe inertia and back-compatibity and the rare use case won. reinforces the point that if you only want to test whether you have None, you should use is not None rather than relying on __bool__. Right. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Implicit conversion to boolean in if and while statements
On 7/15/2012 1:02 PM, Andrew Berg wrote:
On 7/15/2012 5:56 AM, Steven D'Aprano wrote:
3) Rather than distinguishing true from false, a more useful
dichotomy is between something and nothing. Python includes a number
of ways of spelling nothing of various types, such as:
None, 0, 0.0, '', [], {}, set()
and nearly everything else is something.
Okay, I see the value in this, but I don't understand why None has a
truth value.
Because everything does (or should).
I would expect None to mean doesn't exist or unknown or
something like that - e.g., a value of 0 means 0 jelly beans in the jar
and None means there isn't a jar.
FWIW, I have, for a reason I forget, gotten into the habit of writing
if x is not None when testing for None.
If x might possibly be any other false value (as is, I think, the usual
case), that is the right thing to do. Even if no other false value is
possible, I would still use 'is not None' just to be clear what the
false alternative is, and to guard against mistakes (like not knowing
that time values can be false) or code changes that add the possibility
of ohter false values.
However, I have not been
writing if x is True: .../elif x is False: .../else: 'ruh-roh'
when testing for True (in cases where a value of True or False makes
sense, but any other value would not). Should I?
If you only want to execute the if branch when x is literally the bool
object True and x could be some other non-bool true value such as 1 or
'a' or [1], etc, then you should.
If x is guaranteed to be True or False, which is the case you more or
less proposed, then you should not. For instance, if isinstance(x, int)
is True: or if (n 3) is True: are redundant.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: Implicit conversion to boolean in if and while statements
On Mon, Jul 16, 2012 at 4:56 AM, Rick Johnson rantingrickjohn...@gmail.com wrote: On Sunday, July 15, 2012 1:01:58 PM UTC-5, Ian wrote: So now instead of having to understand how if handles arbitrary values, we have to understand how bool handles arbitrary values. How is that an improvement? Because we are keeping the condition consistent. We are not relying on implicit resolution of an object's value based on some dark, esoteric and inconsistent rules that defy all normal logic. What should if do if presented a value that isn't True or False? Raise a TypeError? YES! Because IT IS the author's responsibility to present a condition that evaluates to either True or False. Anything else would be ridiculously inconsistent. Then the construct if bool(some_condition): is redundant. What you've described is a viable system (REXX, for instance, demands that an IF statement be given strictly either a 1 or a 0 (there's no True and False values, but you're not allowed to use 527 as a True value, it has to be 1)), but it's still redundant to attempt the cast. For instance, this REXX function will logically negate a value twice, thus forcing it to boolean: bool: procedure return \\arg(1) But if it's given a non-bool, it'll just bomb, exactly the same as the if statement would. So Ian's point still stands. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Implicit conversion to boolean in if and while statements
On Jul 15, 4:53 pm, Chris Angelico ros...@gmail.com wrote: Then the construct if bool(some_condition): is redundant. Wrong again, pay attention Chris! It's ONLY redundant IF some_condition is a rich comparison: like (a==b) OR a boolean function: like callable(a). If HOWEVER we want to truth test an object (as in: if obj) we should be FORCED to use the bool! Why? Because explicit is better than implicit and readability counts if we want to create maintainable code bases! if bool(obj) and a==b: # Correct! if obj and a==b: # Incorrect! Both lines of code currently produce the same result because somebody decided to give objects esoteric boolean values. Sure, we saved a few key stokes in a condition, but sadly at the cost of readability and consistency. I see no reason why choosing implicit resolution is better than explicit resolution. Saving six keystrokes is simply not enough! Python's motto has always been readability counts, and for that reason, we should return to Explicit Boolean Resolution if we want to adhere to those principals. -- http://mail.python.org/mailman/listinfo/python-list
Diagramming code
Is there any software to help understand python code ? Thanks hamilton -- http://mail.python.org/mailman/listinfo/python-list
Re: Diagramming code
On Sun, Jul 15, 2012 at 6:26 PM, hamilton hamil...@nothere.com wrote: Subject: Diagramming code Is there any software to help understand python code ? What sort of diagrams? Control flow diagrams? Class diagrams? Sequence diagrams? Module dependency diagrams? There are many different types you could be referring to. Here's a relatively comprehensive list: http://en.wikipedia.org/wiki/Unified_Modeling_Language#Diagrams_overview Regards, Chris -- UML: Kill it with fire! -- http://mail.python.org/mailman/listinfo/python-list
Re: Implicit conversion to boolean in if and while statements
On Mon, Jul 16, 2012 at 11:21 AM, Ranting Rick rantingrickjohn...@gmail.com wrote: If HOWEVER we want to truth test an object (as in: if obj) we should be FORCED to use the bool! Why? Because explicit is better than implicit and readability counts if we want to create maintainable code bases! if bool(obj) and a==b: # Correct! if obj and a==b: # Incorrect! That still doesn't answer the question of what bool(obj) should do if obj is not a bool, and why if can't do the exact same thing, since if, by definition, is looking for a boolean state selector. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Diagramming code
On 7/15/2012 7:38 PM, Chris Rebert wrote: On Sun, Jul 15, 2012 at 6:26 PM, hamilton hamil...@nothere.com wrote: Subject: Diagramming code Is there any software to help understand python code ? What sort of diagrams? Control flow diagrams? Class diagrams? Sequence diagrams? Module dependency diagrams? There are many different types you could be referring to. Here's a relatively comprehensive list: http://en.wikipedia.org/wiki/Unified_Modeling_Language#Diagrams_overview Regards, Chris -- UML: Kill it with fire! OK then, let me ask, how do you guys learn/understand large projects ? hamilton -- http://mail.python.org/mailman/listinfo/python-list
Re: Diagramming code
On Sun, Jul 15, 2012 at 6:57 PM, hamilton hamil...@nothere.com wrote: On 7/15/2012 7:38 PM, Chris Rebert wrote: On Sun, Jul 15, 2012 at 6:26 PM, hamilton hamil...@nothere.com wrote: Subject: Diagramming code Is there any software to help understand python code ? What sort of diagrams? Control flow diagrams? Class diagrams? Sequence diagrams? Module dependency diagrams? There are many different types you could be referring to. Here's a relatively comprehensive list: http://en.wikipedia.org/wiki/Unified_Modeling_Language#Diagrams_overview Regards, Chris -- UML: Kill it with fire! OK then, let me ask, how do you guys learn/understand large projects ? In case you're responding to my trailing semi-satirical comment, let me clarify: I was remarking on UML specifically, not software-related diagrams in general. Cheers, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Implicit conversion to boolean in if and while statements
On Sun, 15 Jul 2012 10:19:16 -0600, Ian Kelly wrote:
On Sun, Jul 15, 2012 at 4:56 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
(For the record, I can only think of one trap for the unwary: time
objects are false at *exactly* midnight.)
Ugh, that's irritating. I can't think of any scenario where I would
ever want the semantics if timeval (is not midnight):.
Yes, it is a genuine gotcha. Time values are numbers, and zero is falsey,
so midnight is falsey even though it shouldn't be.
There's no good solution here, since we have a conflict between treating
time values as time values (midnight is nothing special) and as numbers
(midnight == 0 which is falsey). The only solution is to throw out
duck-typing of boolean values, which is tossing the baby out with the
bathwater -- bool duck-typing works fine for everything else.
This
reinforces the point that if you only want to test whether you have
None, you should use is not None rather than relying on __bool__.
Often you should, but I didn't mention anything about testing for None.
Testing objects in a boolean context is more than just testing for None.
I have just written a bunch of code with about two dozen examples similar
to this:
for item in (seq or []):
do_something_with(item)
iterates over seq if it is non-empty, or the empty list. Writing it like
this would be more painful, more complex, less readable and less
idiomatic:
if seq is not None:
for item in seq:
do_something_with(item)
not to mention completely unnecessary if you have already checked that
seq is either None or a sequence, and not some other arbitrary value.
(If seq really could be any type at all, then an explicit identity test
against None is required.)
One of my favourites:
value = (dict or {}).get('key')
instead of:
value = None if dict is None else dict.get('key')
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Implicit conversion to boolean in if and while statements
On Sun, Jul 15, 2012 at 9:51 PM, Chris Angelico ros...@gmail.com wrote: if bool(obj) and a==b: # Correct! if obj and a==b: # Incorrect! That still doesn't answer the question of what bool(obj) should do if obj is not a bool, and why if can't do the exact same thing, since if, by definition, is looking for a boolean state selector. If can obviously do the exact same thing -- it does, in Python. I don't agree with the angle that Rick is spinning, so let me write my own: By forcing the objects in conditional to be booleans, you are forced to do something to non-booleans to convert them. By doing so, you will help inform the reader what the non-boolean is, which makes it easier for them to figure out the code. For example, instead of if stack: or if bool(stack):, we could use if stack.isempty():. This line tells us explicitly that stack is a container. Or instead of if dist: or if bool(dist): we could use if dist == 0:. This tells us explicitly that stack is a number. Supposedly this makes it easier to read code. It certainly reads more like English! :) As far as I know, the only use of having a polymorphic boolean conversion is reducing the amount of typing we do. Generally objects with otherwise different interfaces are not interchangeable just because they can be converted to booleans, so you wouldn't lose much by being forced to explicitly convert to boolean with something interface-specific. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Implicit conversion to boolean in if and while statements
On Jul 15, 8:51 pm, Chris Angelico ros...@gmail.com wrote: On Mon, Jul 16, 2012 at 11:21 AM, Ranting Rick rantingrickjohn...@gmail.com wrote: If HOWEVER we want to truth test an object (as in: if obj) we should be FORCED to use the bool! Why? Because explicit is better than implicit and readability counts if we want to create maintainable code bases! if bool(obj) and a==b: # Correct! if obj and a==b: # Incorrect! That still doesn't answer the question of what bool(obj) should do if obj is not a bool, and why if can't do the exact same thing, since if, by definition, is looking for a boolean state selector. ChrisA My point is no different than this example: py cost = 1.75 py cost 1.75 py 'Cost = ' + cost Traceback (most recent call last): File pyshell#17, line 1, in module 'Cost = ' + cost TypeError: cannot concatenate 'str' and 'float' objects py 'Cost = ' + str(cost) 'Cost = 1.75' We DON'T want Python to silently convert cost to a string. What we DO want is to force the author to use the str function thereby making the conversion explicit. Same with converting objects to bools. We DON'T want if to magically convert a non-boolean into a boolean. What we DO want is to force the author to use the bool function thereby making the conversion explicit. By doing so we transform confusion into comprehension. By doing so we maintain the principals of readability counts. -- http://mail.python.org/mailman/listinfo/python-list
Re: Implicit conversion to boolean in if and while statements
On Sun, 15 Jul 2012 12:02:37 -0500, Andrew Berg wrote:
On 7/15/2012 5:56 AM, Steven D'Aprano wrote:
3) Rather than distinguishing true from false, a more useful
dichotomy is between something and nothing. Python includes a
number of ways of spelling nothing of various types, such as:
None, 0, 0.0, '', [], {}, set()
and nearly everything else is something.
Okay, I see the value in this, but I don't understand why None has a
truth value.
And this is exactly the sort of mental confusion that Laura Crichton
warned about (see the link I included earlier).
Thinking about truth values is harmful, since that's arbitrary. That
way goes to Javascript, PHP, Ruby etc. that seem to arbitrary pick
whatever things are truthy or falsey according to some random whim, or
according to some implementation detail that is meaningless outside of
the implementation, such as Javascript insisting that while false is
falsey, if you box it in an object it becomes truthy.
It's crap like that which gives duck-typing bools a bad name.
The distinction you should consider is:
- is it something, or nothing?
(relative to the type in question, of course)
Python (at least the built-ins, third-party code can do any old crap they
want) is consistent in this. Instances which represent something/non-
emptiness are true, those which represent nothing/emptiness are false.
0? That's the int that represents nothing, so it's false.
23.723? That's one of many floats that represents something, so it's true.
'spam'? That's one of many non-empty strings, so it's true.
''? That's an empty string, that it, it contains nothing, so it is false.
None? That represents a lack of a thing, that is, nothing, so it's false.
(Please don't get into a great philosophical debate over whether
nothingness is itself something. That impressed me when I was 15. But now
I know about reification: just because we have a name for a concept
doesn't mean that the concept is something concrete. None is an object,
but it *represents* the lack of an object.)
I would expect None to mean doesn't exist or unknown or
something like that - e.g., a value of 0 means 0 jelly beans in the jar
and None means there isn't a jar.
How you interpret some_variable = None depends on what some_variable
represents. If some_variable represents number of jelly beans in a jar,
then that should be 0 if there is no jar.
If you want to create a language with ternary truth values (yes, no, mu)
or some larger number (yes, no, maybe, mu, contradiction, unknowable,
...) be my guest. Just do everyone a favour and do some research on the
large literature on non-boolean logic systems first.
FWIW, I have, for a reason I forget, gotten into the habit of writing
if x is not None when testing for None. However, I have not been
writing if x is True: .../elif x is False: .../else: 'ruh-roh'
when testing for True (in cases where a value of True or False makes
sense, but any other value would not). Should I?
Only if you want people to laugh at you.
If you *genuinely* want to implement Java in Python, then be explicit
about your type-testing:
if isinstance(x, bool) and x: ...
or even
if type(x) is bool and x: ... # disallow subclasses
Otherwise, where do you stop?
if x is True is True is True is True is True is ...
Or you could just write idiomatic Python code, including duck-typing, and
that includes duck-typing bools. Why do you care if somebody calls your
function with flag=1 instead of flag=True?
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Implicit conversion to boolean in if and while statements
On Jul 15, 9:13 pm, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
I have just written a bunch of code with about two dozen examples similar
to this:
for item in (seq or []):
do_something_with(item)
iterates over seq if it is non-empty, or the empty list. Writing it like
this would be more painful, more complex, less readable and less
idiomatic:
if seq is not None:
for item in seq:
do_something_with(item)
not to mention completely unnecessary if you have already checked that
seq is either None or a sequence, and not some other arbitrary value.
Short circuitry is a powerful tool! But why the heck would your
sequences ever be None? Are you using None as a default? And if so,
why not use an empty sequence instead ([], {}, )?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Implicit conversion to boolean in if and while statements
On Mon, Jul 16, 2012 at 12:41 PM, Ranting Rick
rantingrickjohn...@gmail.com wrote:
On Jul 15, 9:13 pm, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
I have just written a bunch of code with about two dozen examples similar
to this:
for item in (seq or []):
do_something_with(item)
Short circuitry is a powerful tool! But why the heck would your
sequences ever be None? Are you using None as a default? And if so,
why not use an empty sequence instead ([], {}, )?
Function default arguments spring to mind, especially if the list will
be mutated afterwards.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: Implicit conversion to boolean in if and while statements
On Jul 15, 9:15 pm, Devin Jeanpierre jeanpierr...@gmail.com wrote: For example, instead of if stack: or if bool(stack):, we could use if stack.isempty():. This line tells us explicitly that stack is a container. Or instead of if dist: or if bool(dist): we could use if dist == 0:. This tells us explicitly that stack is a number. Supposedly this makes it easier to read code. It certainly reads more like English! :) Yes, but this approach involves adding new value testing methods to every object. Whilst these specific methods would probably inject more comprehension than using bool, i believe the bool function can handle this problem better due to its monolithic and generic nature. No need to memorize which method is needed for strings, or integers, or lists, etc... just use bool and everything works. As for the semantics, we should let the object decide how to respond to a __bool__() request. But what's the point of having a bool function if we refuse to use it correctly? We force str, int, and float conversion all day, but not the bool? Where is the consistency? Where is the bool!? -- http://mail.python.org/mailman/listinfo/python-list
Re: Implicit conversion to boolean in if and while statements
On Sun, 15 Jul 2012 18:21:06 -0700, Ranting Rick wrote: If HOWEVER we want to truth test an object (as in: if obj) we should be FORCED to use the bool! Why? Because explicit is better than implicit And this is why Rick always writes code like: integer_value_three = int(1) + int(2) assert (int(integer_value_three) == \ int(3) is True) is True, str(arithmetic failed) list_containing_three_values_which_are_all_integers_but_might_later_have_more_or_fewer_values_or_other_types = list([1, 2, integer_value_three]) because you can never have too much explicitness. Who wouldn't want to read code like that? and readability counts if we want to create maintainable code bases! Yes you, Rick, are correct, that is to say not wrong, that readability, that is to say the quality of ease of reading the text in question, counts, that is to say that it matters to people who care about ease of reading, when our motivation is to create, that is to say write, maintainable code bases, that is to say unified collections of code which can have software errors fixed and new features added with relatively small amounts of effort on behalf of the human programmer. And that, the reason given in the sentence above, is the reason that we, collectively all programmers, should prefer to be explicit, not merely conveying meaning by implication about everything we, collectively all programmers, write, including typing, use of speech-recognition software, or any future technological process by which text or program code or both is transcribed from the idea of the human person to a permanent form recorded where other people, or non-human sentient beings, can read or otherwise gain access to it for the purpose of understanding the content of the test or program code or both. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Implicit conversion to boolean in if and while statements
On Mon, Jul 16, 2012 at 12:58 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: And that, the reason given in the sentence above, is the reason that we, collectively all programmers, should prefer to be explicit, not merely conveying meaning by implication about everything we, collectively all programmers, write, including typing, use of speech-recognition software, or any future technological process by which text or program code or both is transcribed from the idea of the human person to a permanent form recorded where other people, or non-human sentient beings, can read or otherwise gain access to it for the purpose of understanding the content of the test or program code or both. I'd rather be booled in oil. ChrisA *ducks for cover* -- http://mail.python.org/mailman/listinfo/python-list
Re: Implicit conversion to boolean in if and while statements
On Jul 15, 9:58 pm, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: On Sun, 15 Jul 2012 18:21:06 -0700, Ranting Rick wrote: If HOWEVER we want to truth test an object (as in: if obj) we should be FORCED to use the bool! Why? Because explicit is better than implicit And this is why Rick always writes code like: ... Traceback (most recent quip last): Author: DeAprano, line 7, in post LogicalFallacyError: Reductio ad absurdum -- http://mail.python.org/mailman/listinfo/python-list
Re: Implicit conversion to boolean in if and while statements
On Sun, 15 Jul 2012 22:15:13 -0400, Devin Jeanpierre wrote:
For example, instead of if stack: or if bool(stack):, we could use
if stack.isempty():. This line tells us explicitly that stack is a
container.
isempty is not a container method.
py container = []
py container.isempty()
Traceback (most recent call last):
File stdin, line 1, in module
AttributeError: 'list' object has no attribute 'isempty'
Your code tells us explicitly that stack is expected to be an object with
an isempty() method. What does that mean? Who knows?
calories = macdonalds.fries('large')
calories.isempty()
= returns True
When you want to write polymorphic code to handle your stack, you end up
doing something like this:
if isinstance(stack, MyStackClass):
flag = stack.isempty()
else:
try:
# list, collections.deque, many others
flag = len(stack) == 0
except AttributeError:
try:
if sys.version '3':
flag = not stack.__nonzero__()
else:
flag = not stack.__bool__()
except AttributeError:
# Is this even possible in Python 3?
flag = False # I guess...
# If we get here, flag is true if stack is empty.
if flag:
...
Yeah, explicit is *so much better* for readability. Can't you just *feel*
how much more readable all those irrelevant implementation details are?
If you're smart, you wrap all of the above in a function:
def isempty(stack):
# blah blah as above
But if you're *really* smart, you write to the interface and let Python
take care of the polymorphic details for you:
if not stack:
...
(Assuming that stack defines __nonzero__ or __len__ correctly, which it
better if it claims to be a container.)
It boggles my mind that people who are perfectly happy to program to an
interface or protocol when it comes to (say) iterables, numbers or even
big complex classes with dozens of methods, suddenly freak out at the
thought that you can say if obj and obj is duck-typed.
There's a distinct lack of concrete, actual problems from duck-typing
bools, and a heavy over-abundance of strongly-held opinion that such a
thing is self-evidently wrong.
As far as I know, the only use of having a polymorphic boolean
conversion is reducing the amount of typing we do.
The same could be said about *every* polymorphic function.
The benefit is not just because you don't wear out your keyboard as fast.
The benefit is the same for all other polymorphic code: it lets you write
better code faster with fewer bugs and less need for unnecessary type
restrictions.
If there are a few corner cases where you actually *need* to restrict the
type of your flags to a actual bool, well, Python gives you the tools to
do so. Just as you can restrict the type of a sequence to exactly a list
and nothing else, or a number as exactly a float and nothing else. Just
do your type tests before you start operating on the object, and reject
anything that doesn't match what you want.
But that should be the exception, not the rule.
Generally objects
with otherwise different interfaces are not interchangeable just because
they can be converted to booleans, so you wouldn't lose much by being
forced to explicitly convert to boolean with something
interface-specific.
Until somebody writes an awesomely fast stack class in C and gives it an
is_empty() method instead of isempty, and your code can't use it because
you made unnecessary assumptions about the implementation.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Implicit conversion to boolean in if and while statements
On Jul 15, 11:03 pm, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: On Sun, 15 Jul 2012 22:15:13 -0400, Devin Jeanpierre wrote: It boggles my mind that people who are perfectly happy to program to an interface or protocol when it comes to (say) iterables, numbers or even big complex classes with dozens of methods, suddenly freak out at the thought that you can say if obj and obj is duck-typed. if obj is in essence doing if bool(obj) behind the scenes. My question is: Why hide such valuable information from the reader? It's obvious that if bool(obj) will return a boolean; whereas if obj is ambiguous. There's a distinct lack of concrete, actual problems from duck-typing bools, and a heavy over-abundance of strongly-held opinion that such a thing is self-evidently wrong. If the multitudes of misunderstandings from if obj on this list have not convinced you yet, then i lack the energy to educate you! As far as I know, the only use of having a polymorphic boolean conversion is reducing the amount of typing we do. The same could be said about *every* polymorphic function. For which bool IS! Wikipedia to the rescue: In computer science, polymorphism is a programming language feature that allows values of different data types to be handled using a uniform interface. The concept of parametric polymorphism applies to both data types and functions. A function that can evaluate to or be applied to values of different types is known as a polymorphic function. bool(a) - True bool(0) - False bool([1,2,3]) - True bool(True) - True The benefit is not just because you don't wear out your keyboard as fast. The benefit is the same for all other polymorphic code: it lets you write better code faster with fewer bugs and less need for unnecessary type restrictions. There are NO type restrictions for bool. If there are a few corner cases where you actually *need* to restrict the type of your flags to a actual bool, well, Python gives you the tools to do so. Yes, the bool() -- http://mail.python.org/mailman/listinfo/python-list
Re: Implicit conversion to boolean in if and while statements
On Jul 15, 11:20 pm, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: (It's not like explicit and implicit are distinct -- everything depends on something implicit, if only the meaning of the words you use to describe it.) It certainly doesn't mean that the semantics of Python the language must be written out explicitly every time you use each feature. Of course not. Don't be ridiculous. for x in sequence: [...] This syntax is explicit *enough*. We don't need to be any more explicit. But if you are going to argue that if obj is *explicit enough*, then apply your argument consistently to String+1.75 also. Why must we be explicit about string conversion BUT not boolean conversion? Can you reduce this to the absurd? Or will you just choose to ignore this valid point? -- http://mail.python.org/mailman/listinfo/python-list
[issue1767933] Badly formed XML using etree and utf-16
Serhiy Storchaka storch...@gmail.com added the comment:
Thank you, Eli.
However changes to tostring() and tostringlist() break the invariant
b.join(tostringlist(element, 'utf-16')) == tostring(element, 'utf-16'). You
should add followed methods to DataStream:
def seekable(self):
return True
def tell(self):
return len(data)
Note, that monkey-patched version is faster.
stream = io.BufferedIOBase()
stream.writable = lambda: True
stream.write = data.append
stream.seekable = lambda: True
stream.tell = data.__len__
Benchmark results:
tostring() with BytesIO:
$ ./python -m timeit -s import xml.etree.ElementTree as ET;
e=ET.XML('root/') ET.tostring(e, 'utf-16')
1000 loops, best of 3: 268 usec per loop
$ ./python -m timeit -s import xml.etree.ElementTree as ET;
e=ET.XML('root'+'child/'*100+'/root' ) ET.tostring(e, 'utf-16')
100 loops, best of 3: 4.63 msec per loop
tostring() with monkey-patching:
$ ./python -m timeit -s import xml.etree.ElementTree as ET;
e=ET.XML('root/') ET.tostring(e, 'utf-16')
1000 loops, best of 3: 263 usec per loop
$ ./python -m timeit -s import xml.etree.ElementTree as ET;
e=ET.XML('root'+'child/'*100+'/root' ) ET.tostring(e, 'utf-16')
100 loops, best of 3: 3.84 msec per loop
tostringlist() with DataStream class:
$ ./python -m timeit -s import xml.etree.ElementTree as ET;
e=ET.XML('root/') ET.tostringlist(e, 'utf-16')
1000 loops, best of 3: 624 usec per loop
$ ./python -m timeit -s import xml.etree.ElementTree as ET;
e=ET.XML('root'+'child/'*100+'/root' ) ET.tostringlist(e, 'utf-16')
100 loops, best of 3: 4.09 msec per loop
tostringlist() with monkey-patching:
$ ./python -m timeit -s import xml.etree.ElementTree as ET;
e=ET.XML('root/') ET.tostringlist(e, 'utf-16')1000 loops, best of 3: 259
usec per loop
$ ./python -m timeit -s import xml.etree.ElementTree as ET;
e=ET.XML('root'+'child/'*100+'/root' ) ET.tostringlist(e, 'utf-16')
100 loops, best of 3: 3.81 msec per loop
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1767933
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1470548] Bugfix for #1470540 (XMLGenerator cannot output UTF-16)
Serhiy Storchaka storch...@gmail.com added the comment: Here is updated patch with more careful handling of closing (as for issue1767933) and added comments. -- nosy: +eli.bendersky Added file: http://bugs.python.org/file26385/XMLGenerator-3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1470548 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4997] xml.sax.saxutils.XMLGenerator should write to io.RawIOBase.
Serhiy Storchaka storch...@gmail.com added the comment: This issue will be fixed by patch for issue1470548. -- nosy: +storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4997 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15357] Deprecate redundant pieces of pkgutil
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 3987667bf98f by Nick Coghlan in branch 'default': Take the first step in resolving the messy pkgutil vs importlib edge cases by basing pkgutil explicitly on importlib, deprecating its internal import emulation and setting __main__.__loader__ correctly so that runpy still works (Affects #15343, #15314, #15357) http://hg.python.org/cpython/rev/3987667bf98f -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15357 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15343] pydoc -w package writes out page with empty Package Contents section
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 3987667bf98f by Nick Coghlan in branch 'default': Take the first step in resolving the messy pkgutil vs importlib edge cases by basing pkgutil explicitly on importlib, deprecating its internal import emulation and setting __main__.__loader__ correctly so that runpy still works (Affects #15343, #15314, #15357) http://hg.python.org/cpython/rev/3987667bf98f -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15343 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15314] Use importlib instead of pkgutil in runpy
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 3987667bf98f by Nick Coghlan in branch 'default': Take the first step in resolving the messy pkgutil vs importlib edge cases by basing pkgutil explicitly on importlib, deprecating its internal import emulation and setting __main__.__loader__ correctly so that runpy still works (Affects #15343, #15314, #15357) http://hg.python.org/cpython/rev/3987667bf98f -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15314 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15314] Use importlib instead of pkgutil in runpy
Nick Coghlan ncogh...@gmail.com added the comment: OK, I think runpy and __main__.__loader__ are all sorted now. The relevant runpy and command line script tests all check for the expected values, and I added a couple of new tests to cover the -c and reading from stdin cases. -- resolution: - fixed stage: needs patch - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15314 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15272] pkgutil.find_loader accepts invalid module names
Changes by Nick Coghlan ncogh...@gmail.com: -- assignee: - ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15272 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15272] pkgutil.find_loader accepts invalid module names
Nick Coghlan ncogh...@gmail.com added the comment: OK, this one is trickier than I thought - the exact behaviour depends on how you traverse the code, and I believe a PEP 302 importer is technically allowed to accept / in module names. (Unless there's a module names must be valid identifiers in there somewhere that I have forgotten about) Punting on it for the moment. -- assignee: ncoghlan - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15272 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15358] Test pkgutil.walk_packages in test_pkgutil instead of test_runpy
New submission from Nick Coghlan ncogh...@gmail.com: Created to record the egregious hack of relying on the test_runpy infrastructure in order to test pkgutil.walk_packages. It gets the job done, but is a really messy way of going about it. Worth cleaning up by factoring the support code out to a helper module when there isn't a release deadline looming. -- components: Tests messages: 165516 nosy: ncoghlan priority: low severity: normal stage: needs patch status: open title: Test pkgutil.walk_packages in test_pkgutil instead of test_runpy type: enhancement versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15358 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15358] Test pkgutil.walk_packages in test_pkgutil instead of test_runpy
Changes by Nick Coghlan ncogh...@gmail.com: -- dependencies: +pydoc -w package writes out page with empty Package Contents section ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15358 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11322] encoding package's normalize_encoding() function is too slow
Serhiy Storchaka storch...@gmail.com added the comment: I don't know who changed the encoding's package normalize_encoding() function (wasn't me), but it's a really slow implementation. See changeset 54ef645d08e4. -- nosy: +storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11322 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15343] pydoc -w package writes out page with empty Package Contents section
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 9101eab6178c by Nick Coghlan in branch 'default': Issue #15343: Handle importlib.machinery.FileFinder instances in pkgutil.walk_packages (et al) http://hg.python.org/cpython/rev/9101eab6178c -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15343 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15358] Test pkgutil.walk_packages in test_pkgutil instead of test_runpy
Nick Coghlan ncogh...@gmail.com added the comment: Also, a second test case should be added to cover the zipimporter.zipimporter component. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15358 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15358] Test pkgutil.walk_packages in test_pkgutil instead of test_runpy
Changes by Nick Coghlan ncogh...@gmail.com: -- priority: low - normal ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15358 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15343] pydoc -w package writes out page with empty Package Contents section
Nick Coghlan ncogh...@gmail.com added the comment: Fixing this has uncovered another issue: the old import emulation in PEP 302 ignored encoding cookies, thus merrily decoding everything as utf-8 in get_source(). importlib is smarter about this, which means the pydoc tests started failing as they tried to load the files with invalid encoding cookies. I plan to tackle this in two parts: - move get_source() and get_code() in importlib towards consistently raising ImportError, regardless of the reason the result couldn't be provided (chaining the exceptions to ensure details aren't lost) - update pydoc to tolerate ImportError from get_source. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15343 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15343] pydoc -w package writes out page with empty Package Contents section
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 7d202353a728 by Nick Coghlan in branch 'default': Issue #15343: A lot more than just unicode decoding can go wrong when retrieving a source file http://hg.python.org/cpython/rev/7d202353a728 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15343 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9319] imp.find_module('test/badsyntax_pep3120') causes segfault
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset ce0687a8383b by Nick Coghlan in branch 'default': Issue #9319: Remove the workaround for this since fixed problem from pydoc http://hg.python.org/cpython/rev/ce0687a8383b -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9319 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15343] pydoc -w package writes out page with empty Package Contents section
Nick Coghlan ncogh...@gmail.com added the comment: Main change in that last commit is really the one to make pydoc ignore just about *any* exception from get_source(). This should make it more robust against buggy loaders, too. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15343 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15343] pydoc -w package writes out page with empty Package Contents section
Nick Coghlan ncogh...@gmail.com added the comment: And a manual check confirms the higher level issue is also fixed. (I believe there's already a meta issue somewhere about the lack of automated tests for pydoc's emitted HTML) -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15343 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15357] Deprecate redundant pieces of pkgutil
Nick Coghlan ncogh...@gmail.com added the comment: I'm pretty sure I got them all while fixing #15343 -- resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15357 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15356] '\xa0' isspace returns true while compiling python on solaris 10 by users using gcc 3.4.6
R. David Murray rdmur...@bitdance.com added the comment: I'm sorry, It looks like you said it was working as you expected in 2.7, and you marked it for version 2.6. So what is the bug that you see in 2.7? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15356 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15359] Sockets support for CAN_BCM
New submission from Brian Thorne hardb...@gmail.com: In addition to CAN_RAW introduced in Python 3.3, it would be really useful to expose the CAN_BCM protocol. Effectively it hands off as much to the kernel as possible which gives Python programs the ability to send and receive many periodic messages with little additional jitter or overhead. I've attached an early stab at a patch to see if there is interest. I'll be putting more examples of using BCM sockets at https://bitbucket.org/hardbyte/python-socket-examples -- components: Library (Lib) files: python_bcm.patch keywords: patch messages: 165527 nosy: Thorney, pitrou priority: normal severity: normal status: open title: Sockets support for CAN_BCM type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file26386/python_bcm.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15359 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15359] Sockets support for CAN_BCM
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +neologix ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15359 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15356] '\xa0' isspace returns true while compiling python on solaris 10 by users using gcc 3.4.6
zoupl zoupen...@gmail.com added the comment: No, i mean it works ok on version 2.7. However, what I want to know is the way that works in version2.7, because I want to try to fix it in version 2.6. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15356 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15180] Cryptic traceback from os.path.join when mixing str bytes
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset cf1ac0c9e753 by Hynek Schlawack in branch '3.2': #15180: Clarify posixpath.join() error message when mixing str bytes http://hg.python.org/cpython/rev/cf1ac0c9e753 New changeset 1462b963e5ce by Hynek Schlawack in branch 'default': #15180: Clarify posixpath.join() error message when mixing str bytes http://hg.python.org/cpython/rev/1462b963e5ce -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15180 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15180] Cryptic traceback from os.path.join when mixing str bytes
Hynek Schlawack h...@ox.cx added the comment: Fixed for 3.2 default. -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15180 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15307] Patch for --symlink support in pyvenv with framework python
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset f954ee489896 by Vinay Sajip in branch 'default': Issue #15307: Skipped test_venv:test_prefixes when run from a venv. http://hg.python.org/cpython/rev/f954ee489896 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15307 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15356] '\xa0' isspace returns true while compiling python on solaris 10 by users using gcc 3.4.6
R. David Murray rdmur...@bitdance.com added the comment: Ah. I have no idea. I did a search and could not find an issue about it being fixed...that doesn't mean there wasn't one, though. Does the problem occur *only* solaris? Because if it isn't solaris specific it might be this one: issue 1571184. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15356 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15349] SyntaxError b0rked grammar
Roger Serwy roger.se...@gmail.com added the comment: Thank you for the bug report, Ztatik. Since 2.6 is now in security-fix-only mode, this issue will not be fixed. See http://www.python.org/getit/releases/2.6.8/ This grammar issue was fixed in 2.7 with revision 386922b629c3, but was not applied to the 2.6 series at the time. If you find any more errors, please report them. -- nosy: +serwy resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15349 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15351] Add to unittest.TestCase support for using context managers
Michael Foord mich...@voidspace.org.uk added the comment: A method on TestCase that *just* executes the test method - allowing for overriding in subclasses - is an interesting idea. Including setUp and tearDown would be harder because TestCase necessarily does a bunch of bookkeeping between each of these steps. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15351 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15202] followlinks/follow_symlinks/symlinks flags unification
Antoine Pitrou pit...@free.fr added the comment: The .4 patches both LGTM, please commit! You're the one with commit rights here ;) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15202 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15233] atexit: guarantee order of execution of registered functions?
Antoine Pitrou pit...@free.fr added the comment: Shall I also backport to 2.7 and 3.2 as the issue suggests? If the tests are there, yes! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15233 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14787] pkgutil.walk_packages returns extra modules
Chris Jerdonek chris.jerdo...@gmail.com added the comment: For the record, this issue is still present after Nick's pkgutil changes documented in issue 15343 (not that I expected it to be resolved since this issue is a bit different). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14787 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15358] Test pkgutil.walk_packages in test_pkgutil instead of test_runpy
Changes by Chris Jerdonek chris.jerdo...@gmail.com: -- nosy: +cjerdonek ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15358 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15360] Behavior of assigning to __dict__ is not documented
New submission from Davide Rizzo sor...@gmail.com: The documentation (at least the obvious places, see Doc/reference/datamodel.rst) says classes and class instances have the '__dict__' attribute, but nothing is said about what happens when assigning to it (like obj.__dict__ = something). As far as I understand that's undefined behavior and other implementations may not work the same as CPython (and CPython itself behaves differently between versions). I'd submit a documentation patch if I knew how to specify this matter. Maybe just say the behavior is not defined? -- assignee: docs@python components: Documentation, Interpreter Core messages: 165538 nosy: davide.rizzo, docs@python priority: normal severity: normal status: open title: Behavior of assigning to __dict__ is not documented versions: Python 2.7, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15360 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15297] pkgutil.iter_importers() includes an ImpImporter
Chris Jerdonek chris.jerdo...@gmail.com added the comment: Closing as this is no longer an issue after Nick's pkgutil changes documented in issue 15343. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15297 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15358] Test pkgutil.walk_packages in test_pkgutil instead of test_runpy
Chris Jerdonek chris.jerdo...@gmail.com added the comment: Such helper functionality could also be used in the tests of unittest.TestLoader.loadTestsFromName(). See, for example, the tests proposed for issue 7559. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15358 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8229] Interpreter crash on application shutdown
Roger Serwy roger.se...@gmail.com added the comment: tb220, is this still a bug? Python 2.6 is now in security-fix-only mode. -- nosy: +serwy status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8229 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15202] followlinks/follow_symlinks/symlinks flags unification
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 758a9023d836 by Larry Hastings in branch 'default': Issue #15202: Consistently use the name follow_symlinks for http://hg.python.org/cpython/rev/758a9023d836 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15202 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14988] _elementtree: Raise ImportError when importing of pyexpat fails
Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com added the comment: IMHO wrong exception could be treated as a bug, which could be fixed in 3.2 and 3.3. Benjamin Peterson and Georg Brandl: What do you think? P.S. is there any way to create a test for it? You can set sys.modules[pyexpat]=None and test exception type when trying to import _elementtree. -- nosy: +benjamin.peterson, georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14988 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15352] importlib.h should be regenerated when the marshaling code changes
Meador Inge mead...@gmail.com added the comment: Eric, that is a good point, but if someone forgets (like I did) or just hasn't gotten around to bumping the number yet, then the build breaks because the interpreter crashes. I think we should always try to avoid building an interpreter that is in an inconsistent state. Anyway, I am hitting another problem now -- _freeze_importlib is *not* idempotent. Thus adding this rule might cause some noise in the builds because importlib.h is different when nothing has actually changed. I am still investigating that problem. Assuming I can fix the idempotency problem, then maybe _freeze_importlib should just be always run. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15352 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15361] venv's Activate.ps1 causes broken prompt with powershell
New submission from Richard Oudkerk shibt...@gmail.com:
If I create a venv on Windows called py3 then py3/Scripts/Activate.ps1
defines the prompt to be
function prompt {
Write-Host -NoNewline -ForegroundColor Green [(py3) ]
_OLD_VIRTUAL_PROMPT
}
However this prompt function does not work properly, and running
Write-Host -NoNewline -ForegroundColor Green [(py3) ]
on its own produces an error because of the lack of quotes around (py3).
Adding quotes as shown in the patch seems to fix the problem.
--
components: Library (Lib)
files: prompt.patch
keywords: patch
messages: 165545
nosy: sbt, vinay.sajip
priority: normal
severity: normal
stage: patch review
status: open
title: venv's Activate.ps1 causes broken prompt with powershell
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file26387/prompt.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15361
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9374] urlparse should parse query and fragment for arbitrary schemes
Éric Araujo mer...@netwok.org added the comment: Removing the module attributes causes third-party code to break. See one example here: http://lists.idyll.org/pipermail/testing-in-python/2012-July/005082.html -- status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9374 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9374] urlparse should parse query and fragment for arbitrary schemes
Éric Araujo mer...@netwok.org added the comment: Better link: https://github.com/pypa/pip/issues/552 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9374 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15202] followlinks/follow_symlinks/symlinks flags unification
Éric Araujo mer...@netwok.org added the comment: There are versionadded notes in the doc that still use the old names (e.g. symlinks for shutil.copyfile). -- nosy: +eric.araujo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15202 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15361] venv's Activate.ps1 causes broken prompt with powershell
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 0b4d0c2173ad by Vinay Sajip in branch 'default': Closes #15361: Corrected venv prompt in PowerShell activation script. http://hg.python.org/cpython/rev/0b4d0c2173ad -- nosy: +python-dev resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15361 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15362] pyport.h includes antiquated UTF handling for FreeBSD
New submission from John Schneider j...@jschneider.com: Revision 36793 introduced a libc wrapper for FreeBSD 5.x which addressed some UTF issues. Unfortunately, this causes C compilation errors for certain ports. Also reference issues 10910, 1455641 This change is no longer applicable for FreeBSD 9. I'm not sure what version of FreeBSD made it not longer applicable, but there were reports of it still being necessary for FreebSD 7. FreeBSD 6 - 8 should be tested with this test script: #!/usr/bin/env python from ctypes import * cdll.LoadLibrary(libc.so.7) libc = CDLL(libc.so.7) assert libc.isspace(0xa0) == 0 I've also attached a patch for python 2.7.3. -- components: Unicode, ctypes files: patch-pyport.h messages: 165550 nosy: JohnSchneider, ezio.melotti priority: normal severity: normal status: open title: pyport.h includes antiquated UTF handling for FreeBSD versions: Python 2.7 Added file: http://bugs.python.org/file26388/patch-pyport.h ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15362 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12978] Figure out extended attributes on BSDs
koobs koobs.free...@gmail.com added the comment:
FreeBSD (at least on 7.x, 8.x and 9.x) has the following syscalls available in
its API:
extattr_{get,set,list,delete}_{fd,file,link}
And also has: EXTATTR_MAXNAMELEN
http://www.freebsd.org/cgi/man.cgi?query=extattrsektion=2manpath=FreeBSD+9.0-RELEASE
--
nosy: +koobs
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12978
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
