Re: PEAK-Rules package.
Hi, Thanks for the reply! I do see different revisions of PEAK-Rules listed on - http://peak.telecommunity.com/snapshots/. However, earlier as part our product installation PEAK-Rules>=0.5a1.dev-r2600 dependency was being fulfilled using easy_install default behavior. So, I think https://pypi.python.org/simple/PEAK-Rules/ had the right package available earlier. Could you please let me know if the above link has been changed. - Radhika On Thu, Dec 31, 2015 at 1:43 AM, Joel Goldstick wrote: > > > On Wed, Dec 30, 2015 at 8:24 AM, Radhika Grover > wrote: > >> Hi, >> >> I don't see any package available under >> https://pypi.python.org/simple/PEAK-Rules/. Could you please let me know >> if it has seen a change recently. >> >> I need PEAK-Rules>=0.5a1.dev-r2600 using easy_install default behavior. >> Any help is appreciated. Thanks in advance! >> >> - Radhika >> -- >> https://mail.python.org/mailman/listinfo/python-list >> > > https://pypi.python.org/pypi/PEAK-Rules maybe? > > -- > Joel Goldstick > http://joelgoldstick.com/stats/birthdays > -- https://mail.python.org/mailman/listinfo/python-list
fabric.network.disconnect_all()
hi team,
I am not sure that disconnect_all() works correctly for task marked as
@parallel
Following is code snippet -
@parallel
def diagnoseTransaction():
with hide('stdout', 'stderr'):
output = run(command)
main.py:
execute(diagnoseTransaction,hosts=hosts_transaction)
disconnect_all()
In the console I see all the commands ran but I never saw
'Disconnecting message' in the console.
While if I remove @parallel decorator and then if I run the same code
then I do see 'Disconnecting messages' in the console.
Am I missing something or ?
Thanks,
Ankur
--
https://mail.python.org/mailman/listinfo/python-list
Re: how to get names of attributes
On Thu, 31 Dec 2015 10:58:17 +1100, Steven D'Aprano wrote: (some very good information) Thank you. -- https://mail.python.org/mailman/listinfo/python-list
Re: using __getitem()__ correctly
On Thu, 31 Dec 2015 10:50:53 +1100, Steven D'Aprano wrote: > I'm not sure what distinction you're referring to, can you explain? Ian Kelly had said: >> How precisely are you trying to store these: as an attribute, or as a >> dict item? If it's supposed to be in the dict, then why is your >> __getitem__ trying to look up an attribute to begin with? to which I answered: >> In any case, I thought that class attributes were, in fact, items of >>__dict__? > > Obviously there is a syntax difference between x.attr and x['key'], but > attributes *are* items in a dictionary (ignoring __slots__ and > __getattr__ for the time being). Either the instance __dict__, the class > __dict__, or a superclass __dict__. That was my understanding but I wasn't sure what Ian meant when he went on to say: >> If it's supposed to be in the dict, then why is your __getitem__ >> trying to look up an attribute to begin with? Which raises the question of where they would be if not in a dictionary. This brings up a fundamental unclarity of mine: an object has attributes, one of which is __dict__, which has attributes. - how does one access the attributes in e.g. self - where do I find the attribute 'mcc' by cruising around in pdb, given the objs below? (PDB)pp dir (self) ['__class__', '__cmp__', ... '__dict__', ... '__weakref__', 'clear', 'copy', 'fromkeys', 'get', 'has_key', 'items', 'iteritems', 'iterkeys', 'itervalues', 'keys', 'pop', 'popitem', 'setdefault', 'update', 'values'] (PDB)pp dir (self.__dict__) ['__class__', '__cmp__', ... '__delitem__', '__doc__', ... '__str__', '__subclasshook__', 'clear', 'copy', 'fromkeys', 'get', 'has_key', 'items', 'iteritems', 'iterkeys', 'itervalues', 'keys', 'pop', 'popitem', 'setdefault', 'update', 'values'] (PDB)pp (self.keys()) ['mcc'] It was recommended that I use the obj[name] syntax in __getattr__() but that then invoked __getitem__(), complicating the matter. To be specific, if an attribute is not available, I want to assume it's a graph node and create it. If the attribute has an index, I want to create and access an array of those nodes. It seems to fall perfectly within the definition of __getattr__() and __getitem__(), but I suspect that slight programming errors (i.e. mine) are hiding the proper functionality of these methods. Thanks everybody, for your help so far, and hopefully you can me pointed in the right direction. Happy New Year! cts -- https://mail.python.org/mailman/listinfo/python-list
Re: using __getitem()__ correctly
On Thu, 31 Dec 2015 11:21:59 +1100, Ben Finney wrote: > Steven D'Aprano writes: > >> On Thu, 31 Dec 2015 10:13 am, Ben Finney wrote: >> >> > You may be familiar with other languages where the distinction >> > between “attribute of an object” is not distinct from “item in a >> > dictionary”. Python is not one of those languages; the distinction is >> > real and important. ... > > Tersely: the relationship between an object and its attributes, is not > the same as the relationship between a dictionary and its items. I understand this to mean that the relationship between a dictionary and its items is less complex than the relationship between an object and its attributes. I'd like to catalog the different attribute types/implications: - perhaps a hierarchy of meta-ism - or user-relevance - those things in the __dict__ - those things not in the __dict__ but without the "__" - ??? > >> Obviously there is a syntax difference between x.attr and x['key'] > > Not merely syntax; the attributes of an object are not generally > available as items of the container. What are the set of ways that an attribute is accessible? Including implementation implications? > >> Either the instance __dict__, the class __dict__, or a superclass >> __dict__. > > No, I'm not referring to the ‘__dict__’ attribute of an object; I'm > referring to the object itself. > > To talk about the attributes of an object ‘foo’ is distinct from talking > about the items in a dictionary ‘foo’. That distinction is real, and > important. But wanting to deal with the attributes of an object without considering the way it's implemented - although possible - requires a complete virtual model that covers all implications. It's easier to simply understand how the objects work under the covers. -- https://mail.python.org/mailman/listinfo/python-list
Re: using __getitem()__ correctly
"Charles T. Smith" writes: > On Thu, 31 Dec 2015 11:21:59 +1100, Ben Finney wrote: > > > Tersely: the relationship between an object and its attributes, is > > not the same as the relationship between a dictionary and its items. > > I understand this to mean that the relationship between a dictionary > and its items is less complex than the relationship between an object > and its attributes. That's not implied by the above, nor is it what I meant. I meant that the relationship is not the same. * The attributes of an object ‘foo’ are what you access via ‘foo.bar’ syntax. You don't access those attributes via ‘foo[bar]’. * The items of a dictionary ‘foo’ are what you access via ‘foo[bar]’ syntax. You don't access those items via ‘foo.bar’. That's an important, and real, difference. And it's much better learned as part of a comprehensive course on Python, not in a deep dive into the magic methods. I really don't know why it's been so difficult to talk about this, but I hope my meaning is clear now. Have a wonderful end of year, folks. -- \ “There are no chaplains in foxholes.” —Sergeant Justin | `\ Griffith, 2011-07-27 | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: using __getitem()__ correctly
On 31 December 2015 at 11:30, Charles T. Smith
wrote:
>>> Obviously there is a syntax difference between x.attr and x['key']
>>
>> Not merely syntax; the attributes of an object are not generally
>> available as items of the container.
>
>
> What are the set of ways that an attribute is accessible? Including
> implementation implications?
>
>
>>
>>> Either the instance __dict__, the class __dict__, or a superclass
>>> __dict__.
>>
>> No, I'm not referring to the ‘__dict__’ attribute of an object; I'm
>> referring to the object itself.
>>
>> To talk about the attributes of an object ‘foo’ is distinct from talking
>> about the items in a dictionary ‘foo’. That distinction is real, and
>> important.
>
>
> But wanting to deal with the attributes of an object without considering
> the way it's implemented - although possible - requires a complete virtual
> model that covers all implications. It's easier to simply understand how the
> objects work under the covers.
When you write x.attr the name 'attr' is looked up on the object x.
This calls x.__getattribute__('attr'). In turn this checks the dict
associated with the object x i.e. x.__dict__['attr']. This in turn
calls x.__dict__.__getitem__('attr'). The lookup of x.__dict__ is
special and doesn't use the normal __getattribute__ mechanism
(otherwise this would be an infinite recursion). Generally special
attributes (with double underscores) are looked up in a different way.
If x.__dict__ does not have the attribute then the dict associated
with the class/type of x is checked i.e. x.__class__.__dict__['attr'].
The lookup of x.__class__ is also special. Failing this the other
classes in x.__class__.__mro__ are checked i.e.
x.__class__.__mro__[1].__dict__['attr']. Once these are exhausted
x.__getattribute__('attr') falls back on calling
x.__getattr__('attr').
IIUC you're trying to create an attribute dict where the same
attributes can be looked up via x.attr or x['attr'] (i.e.
x.__getattribute__('attr') or x.__getitem__('attr')). One way to do
this is to subclass dict and then set each instances __dict__ to be
itself. This way __getattribute__ will search the instance (which is a
dict subclass) as its own attribute dict. You can then use __getattr__
as the fallback for attributes that are not found. A simple
implementation of this could look like:
class attrdict(dict):
def __init__(self, name=None):
self.__dict__ = self
kwargs = {'name':name} if name is not None else {}
super(attrdict, self).__init__(**kwargs)
def __getattr__(self, attrname):
ob = self[attrname] = type(self)(name=attrname)
return ob
>>> d = attrdict('foo')
>>> d
{'name': 'foo'}
>>> d.bar
{'name': 'bar'}
>>> d
{'bar': {'name': 'bar'}, 'name': 'foo'}
The problem with this as with any dict subclass approach is that a
dict has a load of methods (.items() .keys() .pop() ...) that will now
become conflated with your dict keys when you use the attribute
access:
>>> d.items
This means that you can't use any of the dict method names in whatever
you're doing. This is the reason that a dict uses a different
mechanism __getitem__ so that it can store arbitrary keys at the same
time as having named methods which must be attributes. Personally I
think that the best approach is to ditch the idea of conflating
attributes and keys and just use the subscript x['attr'] syntax.
--
Oscar
--
https://mail.python.org/mailman/listinfo/python-list
Re: raise None
On 31 December 2015 at 04:07, Steven D'Aprano wrote: > On Thu, 31 Dec 2015 12:44 pm, Ben Finney wrote: > >> Steven D'Aprano writes: >> >>> Traceback (most recent call last): >>> File "spam", line 19, in this >>> File "spam", line 29, in that >>> File "spam", line 39, in other >>> File "spam", line 5, in _validate >>> ThingyError: ... >>> >>> and the reader has to understand the internal workings of _validate >>> sufficiently to infer that this exception is not a bug in _validate >>> but an expected failure mode of other when you pass a bad argument. >> >> This point seems to advocate for suppressing *any* code that >> deliberately raises an exception. Is that your intent? > > No. The issue isn't that an exception is deliberately raised. The issue is > that it is deliberately raised in a function separate from where the > exception conceptually belongs. The exception is conceptually part of > function "other", and was only refactored into a separate function > _validate to avoid repeating the same validation code in multiple places. > It is a mere implementation detail that the exception is actually raised > inside _validate rather than other. > > As an implementation detail, exposing it to the user (in the form of a line > in the stacktrace) doesn't help debugging. At best it is neutral (the user > reads the error message and immediately realises that the problem lies with > bad arguments passed to other, and _validate has nothing to do with it). At > worst it actively misleads the user into thinking that there is a bug in > _validate. You're overthinking this. It's fine for the error to come from _validate. Conceptually the real error is not in _validate or the function that calls _validate but in whatever function further up the stack trace created the wrong type of object to pass in. If the user can see the stack trace and work back to the point where they passed something in to your function then how does the extra level hurt? If it really bothers you then you can use a comment that will show up in the traceback output _validate(a, b) # Verify arguments to myfunc(a, b) but really I don't think it's a big deal. The traceback gives you useful information about where to look for an error/bug but it's still the programmer's job to interpret that, look at the code, and try to understand what they have done to cause the problem. -- Oscar -- https://mail.python.org/mailman/listinfo/python-list
Re: using __getitem()__ correctly
On Wed, 30 Dec 2015 17:31:11 -0700, Ian Kelly wrote:
>> In any case, I thought that class attributes were, in fact, items of
>> __dict__?
>
> That's correct, but as I said in my previous message, self.attrs and
> self.attrs.__dict__ are two different dicts, and you're confusing one
> for the other. Maybe this will be illuminating:
>
class mydict(dict): pass
> ...
md = mydict()
md['foo'] = 42 # Set an item in md
md['foo'] # 'foo' exists as an item
> 42
md.foo # but not as an attribute
> Traceback (most recent call last):
> File "", line 1, in
> AttributeError: 'mydict' object has no attribute 'foo'
md.__dict__['foo'] # and it's not in md.__dict__
> Traceback (most recent call last):
> File "", line 1, in
> KeyError: 'foo'
md.bar = 43 # Set an attribute on md md.bar # 'bar' exists as an
attribute
> 43
md.__dict__['bar'] # and it's in md.__dict__
> 43
md['bar'] # but it's not in md itself
> Traceback (most recent call last):
> File "", line 1, in
> KeyError: 'bar'
>
> And to hopefully drive the point home:
>
md.items()
> [('foo', 42)]
md.__dict__.items()
> [('bar', 43)]
Okay, I think I got an important point that you said earlier but
I didn't get the full ramifications thereof:
class md (... more about this ...):
pass
md is a class that has an dictionary attribute __dict__:
- md['level1'] puts attributes in md
- md.level2 puts attributes in md.__dict__
is that correct?
Now, as to the superclass, if that's, say, object, then
it has two levels:
md -> object (containing a dict)
if the superclass is dict, then it only has one level:
md -> dict
I'll have to look at my methods again with those understandings.
--
https://mail.python.org/mailman/listinfo/python-list
Re: using __getitem()__ correctly
On Thu, 31 Dec 2015 12:12:43 +, Oscar Benjamin wrote:
> When you write x.attr the name 'attr' is looked up on the object x. This
> calls x.__getattribute__('attr'). In turn this checks the dict
> associated with the object x i.e. x.__dict__['attr']. This in turn calls
> x.__dict__.__getitem__('attr'). The lookup of x.__dict__ is special and
> doesn't use the normal __getattribute__ mechanism (otherwise this would
> be an infinite recursion). Generally special attributes (with double
> underscores) are looked up in a different way. If x.__dict__ does not
> have the attribute then the dict associated with the class/type of x is
> checked i.e. x.__class__.__dict__['attr']. The lookup of x.__class__ is
> also special. Failing this the other classes in x.__class__.__mro__ are
> checked i.e. x.__class__.__mro__[1].__dict__['attr']. Once these are
> exhausted x.__getattribute__('attr') falls back on calling
> x.__getattr__('attr').
Very good overview of the steps, thank you.
...>
> The problem with this as with any dict subclass approach is that a dict
> has a load of methods (.items() .keys() .pop() ...) that will now become
> conflated with your dict keys when you use the attribute access:
>
d.items
>
Yeah, this makes it confusing, too. :)
--
https://mail.python.org/mailman/listinfo/python-list
Re: using __getitem()__ correctly
Hmmm, you seem to be pasting in text from multiple messages, and jumping
around in time ("Ian had said, to which I answered") which may get a bit
confusing. Hopefully I can answer without getting lost :-)
On Thu, 31 Dec 2015 10:17 pm, Charles T. Smith wrote:
> On Thu, 31 Dec 2015 10:50:53 +1100, Steven D'Aprano wrote:
>
>> I'm not sure what distinction you're referring to, can you explain?
I'm pretty sure I was directing that question to Ben, who has explained his
position.
> Ian Kelly had said:
>
>>> How precisely are you trying to store these: as an attribute, or as a
>>> dict item? If it's supposed to be in the dict, then why is your
>>> __getitem__ trying to look up an attribute to begin with?
>
> to which I answered:
>
>>> In any case, I thought that class attributes were, in fact, items of
>>>__dict__?
Ah, but *which* __dict__? There could be many.
Let's put aside some of the technical details which add complexity, and
consider just a simple case: we have an instance "x" of some class X, and
we write "x.spam" to look up the attribute "spam". What happens?
This is equivalent to the function call getattr(x, "spam"), which looks for
an instance attribute, then a class attribute, then in each of the
superclasses (if any). What does getattr do?
We can imagine that it looks something like this simplified version:
def getattr(obj, name):
try:
return obj.__dict__[name]
except KeyError:
for cls in type(obj).__mro__:
try:
return cls.__dict__[name]
except KeyError:
pass
# Still here?
raise AttributeError('not found')
I've skipped a lot of detail -- calling of __getattribute__ and __getattr__
methods, the possibility of __slots__, the possibility that the instance
doesn't have a __dict__, descriptors, the influence of the metaclass,
differences between classic and new-style classes -- but the above shows
the essentials: an attribute lookup may look in multiple dicts to find the
attribute.
The astute reader will notice that inside getattr() I'm doing an attribute
lookup "obj.__dict__". How does that not trigger an endless series of
recursive calls to getattr?
The answer is that a handful of special attributes, including __dict__, are
built into the structure of the object itself, not part of the __dict__,
and so the Python interpreter can find them without looking in the dict.
Don't worry about it -- it's not relevant except in the senses:
(1) the problem of endless recursive calls to getattr() is solved; and
(2) objects can have attributes which aren't actually stored in a dict,
such as __dict__ itself, and __slots__, and probably others.
What those attributes are is, I think, an implementation detail and
irrelevant. So long as you use the existing mechanisms for doing lookups:
x.spam
getattr(x, "spam")
it will just work.
I wrote to Ben:
>> Obviously there is a syntax difference between x.attr and x['key'], but
>> attributes *are* items in a dictionary (ignoring __slots__ and
>> __getattr__ for the time being). Either the instance __dict__, the class
>> __dict__, or a superclass __dict__.
>
>
> That was my understanding but I wasn't sure what Ian meant when he went on
> to say:
>
>>> If it's supposed to be in the dict, then why is your __getitem__
>>> trying to look up an attribute to begin with?
>
> Which raises the question of where they would be if not in a dictionary.
They could be created on the fly by __getattr__ or __getattribute__, they
could be in a __slot__, or they could be a special attribute built into the
object structure. But I don't think that is relevant to Ian's question.
> This brings up a fundamental unclarity of mine: an object has attributes,
> one of which is __dict__, which has attributes.
>
> - how does one access the attributes in e.g. self
self.attribute_name
getattr(self, "attribute_name")
> - where do I find the attribute 'mcc' by cruising around in pdb, given
> the objs below?
What is the object "self" below?
What makes you think that 'mcc' is an attribute? The evidence suggests that
it is not. You write:
dir(self)
and the result does *not* include 'mcc', which is very strong evidence
that 'mcc' is not an attribute.
> (PDB)pp dir (self)
[...]
> 'clear',
> 'copy',
> 'fromkeys',
> 'get',
> 'has_key',
etc. This suggests that "self" is a dict, or specifically a subclass of
dict. So you would have:
class MyDict(dict):
...
x = MyDict()
x.some_method()
and then dropped into the debugger. Now you're looking at the instance x
from inside one of the methods, where it is known as "self". Being a
(subclass of a) dict, it has all the usual dict attributes, like methods
clear, copy, etc., plus whatever extra attributes you give it. There is no
evidence that you have given it any extra attributes.
> (PDB)pp dir (self.__dict__)
[...]
> 'clear',
> 'copy',
> 'fromkeys',
> 'get',
> 'has_key',
etc.
Being an instance, x will usually have
Re: using __getitem()__ correctly
On Thu, 31 Dec 2015 10:30 pm, Charles T. Smith wrote: > On Thu, 31 Dec 2015 11:21:59 +1100, Ben Finney wrote: > >> Steven D'Aprano writes: >> >>> On Thu, 31 Dec 2015 10:13 am, Ben Finney wrote: >>> >>> > You may be familiar with other languages where the distinction >>> > between “attribute of an object” is not distinct from “item in a >>> > dictionary”. Python is not one of those languages; the distinction is >>> > real and important. > ... >> >> Tersely: the relationship between an object and its attributes, is not >> the same as the relationship between a dictionary and its items. > > > I understand this to mean that the relationship between a dictionary and > its items is less complex than the relationship between an object and > its attributes. I think that is a fair comment, since attribute access involves MUCH more complexity than dict item access. Attribute access involves one *or more* dict access, *plus* a whole lot of extra complexity, while dict access by definition involves only a single dict access. > I'd like to catalog the different attribute types/implications: > - perhaps a hierarchy of meta-ism - or user-relevance > - those things in the __dict__ > - those things not in the __dict__ but without the "__" > - ??? I don't discourage you from learning for the sake of learning, but how does this get you closer to solving your actual problem? >>> Obviously there is a syntax difference between x.attr and x['key'] >> >> Not merely syntax; the attributes of an object are not generally >> available as items of the container. I've lost track of who you are quoting here. I think Ben? > What are the set of ways that an attribute is accessible? Including > implementation implications? You can write: x.attr which is equivalent to calling the function: getattr(x, "attr") But really, the only limit is what you program x to do. Python gives you the tools to make (say): x.what_is_my_name()[-1] + None return x.attr, although why would you want to? So let's put aside all the infinite number of weird and wacky ways that you could, with sufficient work, access attributes, and consider only the natural ways to do so. There are two: x.attr getattr(x, "attr") >>> Either the instance __dict__, the class __dict__, or a superclass >>> __dict__. >> >> No, I'm not referring to the ‘__dict__’ attribute of an object; I'm >> referring to the object itself. >> >> To talk about the attributes of an object ‘foo’ is distinct from talking >> about the items in a dictionary ‘foo’. That distinction is real, and >> important. > > > But wanting to deal with the attributes of an object without considering > the way it's implemented - although possible - requires a complete virtual > model that covers all implications. It's easier to simply understand how > the objects work under the covers. You should understand how attributes are implemented, but it is not necessary to understand it in all the gory detail just to use them. Now I'm feeling some sympathy for the people on StackOverflow who told you that you don't need to understand this stuff -- perhaps I was too harsh on them :-) There's a lot of complicated implementation detail involved in attribute access, but for 99% of uses that's all handled for you and all you need do is write x.attr. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: raise None
On Thu, 31 Dec 2015 11:19 pm, Oscar Benjamin wrote: > On 31 December 2015 at 04:07, Steven D'Aprano wrote: [...] >> As an implementation detail, exposing it to the user (in the form of a >> line in the stacktrace) doesn't help debugging. At best it is neutral >> (the user reads the error message and immediately realises that the >> problem lies with bad arguments passed to other, and _validate has >> nothing to do with it). At worst it actively misleads the user into >> thinking that there is a bug in _validate. > > You're overthinking this. Maybe. As I have suggested a number of times now, I'm aware that this is just a marginal issue. But I think it is a real issue. I believe in beautiful tracebacks that give you just the right amount of information, neither too little nor two much. Debugging is hard enough with being given more information than you need and having to decide what bits to ignore and which are important. (Aside: does anyone else hate the tracebacks given by PyCharm? We've had a number of people posting traceback of errors from PyCharm recently, and in my opinion they drown you in irrelevant detail.) > It's fine for the error to come from > _validate. Conceptually the real error is not in _validate or the > function that calls _validate but in whatever function further up the > stack trace created the wrong type of object to pass in. That may be so, but that could be *anywhere* in the call chain. The ultimate cause of the error may not even appear in the call chain. The principle is that errors should be raised as close to their cause as possible. If I call spam(a, b) and provide bad arguments, the earliest I can possibly detect that is in spam. (Only spam knows what it accepts as arguments.) Any additional levels beyond spam (like _validate) is moving further away: File "spam", line 19, in this File "spam", line 29, in that <--- where the error really lies File "spam", line 39, in other File "spam", line 89, in spam <--- the first place we could detect it File "spam", line 5, in _validate <--- where we actually detect it > If the user > can see the stack trace and work back to the point where they passed > something in to your function then how does the extra level hurt? It hurts precisely because it is one extra level. I acknowledge that it is *only* one extra level. (I told you this was a marginal benefit.) If one extra level is okay, might two extra be okay? How about three? What about thirty? Where would you draw the line? > If it really bothers you then you can use a comment that will show up > in the traceback output > > _validate(a, b) # Verify arguments to myfunc(a, b) No, that can't work. (Aside from the fact that in the most general case, the source code may no longer be available to read.) The whole point of moving the validation code into a function was to share it between a number of functions. > but really I don't think it's a big deal. The traceback gives you > useful information about where to look for an error/bug but it's still > the programmer's job to interpret that, look at the code, and try to > understand what they have done to cause the problem. Sure. And I believe that this technique will make the programmer's job just a little bit easier. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: raise None
On Fri, Jan 1, 2016 at 2:35 AM, Steven D'Aprano wrote: >> If the user >> can see the stack trace and work back to the point where they passed >> something in to your function then how does the extra level hurt? > > It hurts precisely because it is one extra level. I acknowledge that it is > *only* one extra level. (I told you this was a marginal benefit.) > > If one extra level is okay, might two extra be okay? How about three? What > about thirty? Where would you draw the line? > It becomes something to get used to when you work with a particular library. Several of my students have run into this with matplotlib or sklearn; you make a mistake with a parameter to function X, which just takes that as-is and passes it to function Y, which does some manipulation but doesn't trip the error, and then calls through to function Z, which notices that one parameter doesn't match another, and raises an exception. You get used to scrolling way up to find the actual cause of the error. Whether that supports or contradicts your point, I'm not sure. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: raise None
On 31/12/2015 00:09, Steven D'Aprano wrote: I have a lot of functions that perform the same argument checking each time: def spam(a, b): if condition(a) or condition(b): raise TypeError if other_condition(a) or something_else(b): raise ValueError if whatever(a): raise SomethingError ... def eggs(a, b): if condition(a) or condition(b): raise TypeError if other_condition(a) or something_else(b): raise ValueError if whatever(a): raise SomethingError ... Since the code is repeated, I naturally pull it out into a function: def _validate(a, b): if condition(a) or condition(b): raise TypeError if other_condition(a) or something_else(b): raise ValueError if whatever(a): raise SomethingError def spam(a, b): _validate(a, b) ... def eggs(a, b): _validate(a, b) ... But when the argument checking fails, the traceback shows the error occurring in _validate, not eggs or spam. (Naturally, since that is where the exception is raised.) That makes the traceback more confusing than it need be. I disagree. So I can change the raise to return in the _validate function: def _validate(a, b): if condition(a) or condition(b): return TypeError if other_condition(a) or something_else(b): return ValueError if whatever(a): return SomethingError and then write spam and eggs like this: def spam(a, b): ex = _validate(a, b) if ex is not None: raise ex ... It's not much of a gain though. I save an irrelevant level in the traceback, but only at the cost of an extra line of code everywhere I call the argument checking function. But suppose we allowed "raise None" to do nothing. Then I could rename _validate to _if_error and write this: def spam(a, b): raise _if_error(a, b) ... and have the benefits of "Don't Repeat Yourself" without the unnecessary, and misleading, extra level in the traceback. Obviously this doesn't work now, since raise None is an error, but if it did work, what do you think? A lot of fuss over nothing. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Where are we in the Python 3 transition?
"Or, how the Kübler-Ross model aptly applies to Python 3". http://www.snarky.ca/the-stages-of-the-python-3-transition -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: raise None
On 31.12.2015 01:09, Steven D'Aprano wrote: > Obviously this doesn't work now, since raise None is an error, but if it did > work, what do you think? I really like the idea. I've approached a similar problem with a similar solution (also experimented with decorators), but the tracebacks really are unintuitive. Unless I missed something, this seems like a nice feature. Cheers, Johannes -- >> Wo hattest Du das Beben nochmal GENAU vorhergesagt? > Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa -- https://mail.python.org/mailman/listinfo/python-list
Re: Where are we in the Python 3 transition?
On Fri, 1 Jan 2016 03:12 am, Mark Lawrence wrote: > "Or, how the Kübler-Ross model aptly applies to Python 3". > > http://www.snarky.ca/the-stages-of-the-python-3-transition Nice link Mark, thanks. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: raise None
On 31 Dec 2015 15:54, "Chris Angelico" wrote: > > On Fri, Jan 1, 2016 at 2:35 AM, Steven D'Aprano wrote: > >> If the user > >> can see the stack trace and work back to the point where they passed > >> something in to your function then how does the extra level hurt? > > > > It hurts precisely because it is one extra level. I acknowledge that it is > > *only* one extra level. (I told you this was a marginal benefit.) > > > > If one extra level is okay, might two extra be okay? How about three? What > > about thirty? Where would you draw the line? > > > > It becomes something to get used to when you work with a particular > library. Several of my students have run into this with matplotlib or > sklearn; you make a mistake with a parameter to function X, which just > takes that as-is and passes it to function Y, which does some > manipulation but doesn't trip the error, and then calls through to > function Z, which notices that one parameter doesn't match another, > and raises an exception. You get used to scrolling way up to find the > actual cause of the error Exactly. The critical technique is looking at the traceback and splitting it between what's your code and what's someone else's. Hopefully you don't need to look at steves_library.py to figure out what you did wrong. However if you do need to look at Steve's code you're now stumped because he's hidden the actual line that raises. All you know now is that somewhere in _validate the raise happened. Why hide that piece of information and complicate the general interpretation of stack traces? Actually matplotlib is a particularly tricky case as often the arguments you pass or stored and not accessed until later. So the traceback shows an error in the call to show() rather than e.g. legend(). Usually I can glean pretty quickly that e.g. the legend labels are at fault though from the traceback though. -- Oscar -- https://mail.python.org/mailman/listinfo/python-list
Re: Need help on a project To :"Create a class called BankAccount with the following parameters "
On 2015-12-25, Gregory Ewing wrote: > Grant Edwards wrote: >> And don't get me started on those people who use those "integrated >> circuits" instead of transistors, relays, and tubes... > > Transistors? You don't know how good you had it. > In my day we had to poke the dopant atoms into > the silicon one at a time with the point of a > needle. You had needles?! -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Python Data Analysis Recommendations
I'm looking for some advice on handling data collection/analysis in Python. I do a lot of big, time consuming experiments in which I run a long data collection (a day or a weekend) in which I sweep a bunch of variables, then come back offline and try to cut the data into something that makes sense. For example, my last data collection looked (neglecting all the actual equipment control code in each loop) like: for t in temperatures: for r in voltage_ranges: for v in test_voltages[r]: for c in channels: for n in range(100): record_data() I've been using Sqlite (through peewee) as the data backend, setting up a couple tables with a basically hierarchical relationship, and then handling analysis with a rough cut of SQL queries against the original data, Numpy/Scipy for further refinement, and Matplotlib to actually do the visualization. For example, one graph was "How does the slope of straight line fit between measured and applied voltage vary as a function of temperature on each channel?" The whole process feels a bit grindy; like I keep having to do a lot of ad-hoc stitching things together. And I keep hearing about pandas, PyTables, and HDF5. Would that be making my life notably easier? If so, does anyone have any references on it that they've found particularly useful? The tutorials I've seen so far seem to not give much detail on what the point of what they're doing is; it's all "how you write the code" rather than "why you write the code". Paying money for books is acceptable; this is all on the company's time/dime. Thanks, Rob -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix. -- https://mail.python.org/mailman/listinfo/python-list
Re: raise None
Hi there,
>>> At worst it actively misleads the user into thinking that there
>>> is a bug in _validate.
Is this "user" a software user or another programmer?
If a software user, then some hint about why the _validate found
unacceptable data might benefit the user's ability to adjust inputs
to the program.
If another programmer, then that person should be able to figure it
out with the full trace. Probably it's not a bug in _validate, but
it could be. So, it could be a disservice to the diagnostician
to exempt the _validate function from suspicion. Thus, I'd want to
see _validate in the stack trace.
>Maybe. As I have suggested a number of times now, I'm aware that
>this is just a marginal issue.
>
>But I think it is a real issue. I believe in beautiful tracebacks
>that give you just the right amount of information, neither too
>little nor two much. Debugging is hard enough with being given more
>information than you need and having to decide what bits to ignore
>and which are important.
I agree about tracebacks that provide the right amount of
information. If I were a programmer working with the code you are
describingi, I would like to know in any traceback that the failed
comparisons (which implement some sort of business logic or sanity
checking) occurred in the _validate function.
In any software system beyond the simplest, code/data tracing would
be required to figure out where the bad data originated.
Since Python allows us to provide ancillary text to any exception,
you could always provide a fuller explanation of the validation
failure. And, while you are at it, you could add the calling
function name to the text to point the programmer faster toward the
probable issue.
Adding one optional parameter to _validate (defaulting to the
caller's function name) would allow you to point the way to a
diagnostician. Here's a _validate function I made up with two silly
comparision tests--where a must be greater than b and both a and b
must not be convertible to integers.
def _validate(a, b, func=None):
if not func:
func = sys._getframe(1).f_code.co_name
if a >= b:
raise ValueError("a cannot be larger than b in " + func)
if a == int(a) or b == int(b):
raise TypeError("a, b must not be convertible to int in " + func)
My main point is less about identifying the calling function or its
calling function, but rather to observe that arbitrary text can be
used. This should help the poor sap (who is, invariably, diagnosing
the problem at 03:00) realize that the function _validate is not the
problem.
>The principle is that errors should be raised as close to their
>cause as possible. If I call spam(a, b) and provide bad arguments,
>the earliest I can possibly detect that is in spam. (Only spam
>knows what it accepts as arguments.) Any additional levels beyond
>spam (like _validate) is moving further away:
>
> File "spam", line 19, in this
> File "spam", line 29, in that <--- where the error really lies
> File "spam", line 39, in other
> File "spam", line 89, in spam <--- the first place we could detect it
> File "spam", line 5, in _validate <--- where we actually detect it
Yes, indeed! Our stock in trade. I never liked function 'that'. I
much prefer function 'this'.
-Martin
Q: Who is Snow White's brother?
A: Egg white. Get the yolk?
--
Martin A. Brown
http://linux-ip.net/
--
https://mail.python.org/mailman/listinfo/python-list
Re: raise None
On Fri, 1 Jan 2016 03:46 am, Oscar Benjamin wrote:
[...]
> Exactly. The critical technique is looking at the traceback and splitting
> it between what's your code and what's someone else's. Hopefully you don't
> need to look at steves_library.py to figure out what you did wrong.
> However if you do need to look at Steve's code you're now stumped because
> he's hidden the actual line that raises. All you know now is that
> somewhere in _validate the raise happened. Why hide that piece of
> information and complicate the general interpretation of stack traces?
No. I don't hide anything. Here's a simple example, minus any hypothetical
new syntax, showing the traditional way and the non-traditional way.
# example.py
def _validate(arg):
if not isinstance(arg, int):
# traditional error handling: raise in the validation function
raise TypeError('expected an int')
if arg < 0:
# non-traditional: return and raise in the caller
return ValueError('argument must be non-negative')
def func(x):
exc = _validate(x)
if exc is not None:
raise exc
print(x+1)
def main():
value = None # on the second run, edit this to be -1
func(value)
main()
And here's the traceback you get in each case. First, the traditional way,
raising directly inside _validate:
[steve@ando tmp]$ python example.py
Traceback (most recent call last):
File "example.py", line 17, in
main()
File "example.py", line 15, in main
func(value)
File "example.py", line 8, in func
exc = _validate(x)
File "example.py", line 3, in _validate
raise TypeError('expected an int')
TypeError: expected an int
What do we see? Firstly, the emphasis is on the final call to _validate,
where the exception is actually raised. (As it should be, in the general
case where the exception is an error.) If you're like me, you're used to
skimming the traceback until you get to the last entry, which in this case
is:
File "example.py", line 3, in _validate
and starting to investigate there. But that's a red herring, because
although the exception is raised there, that's not where the error lies.
_validate is pretty much just boring boilerplate that validates the
arguments -- where we really want to start looking is the previous entry,
func, and work backwards from there.
The second thing we see is that the displayed source code for _validate is
entirely redundant:
raise TypeError('expected an int')
gives us *nothing* we don't see from the exception itself:
TypeError: expected an int
This is a pretty simple exception. In a more realistic example, with a
longer and more detailed message, you might see something like this as the
source extract:
raise TypeError(msg)
where the message is set up in the previous line or lines. This is even less
useful to read.
So it is my argument that the traditional way of refactoring parameter
checks, where exceptions are raised in the _validate function, is
sub-optimal. We can do better.
Here's the traceback we get from the non-traditional error handling. I edit
the file to change the value = None line to value = -1 and re-run it:
[steve@ando tmp]$ python example.py
Traceback (most recent call last):
File "example.py", line 17, in
main()
File "example.py", line 15, in main
func(value)
File "example.py", line 10, in func
raise exc
ValueError: argument must be non-negative
Nothing is hidden. We still see the descriptive exception and error message,
and the line
raise exc
is no worse than "raise TypeError(msg)" -- all the detail we need is
immediately below it.
The emphasis here is on the call to func, since that's the last entry in the
call stack. The advantage is that we don't see the irrelevant call to
_validate *unless we go looking for it in the source code*. We start our
investigate where we need to start, namely in func itself.
Of course, none of this is mandatory, nor is it new. Although I haven't
tried it, I'm sure that this would work as far back as Python 1.5, since
exceptions are first-class values that can be passed around and raised when
required. It's entirely up to the developer to choose whether this
non-traditional idiom makes sense for their functions or not. Sometimes it
will, and sometimes it won't.
The only new part here is the idea that we could streamline the code in the
caller if "raise None" was a no-op. Instead of writing this:
exc = _validate(x)
if exc is not None:
raise exc
we could write:
raise _validate(x)
which would make this idiom more attractive.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Complain
my name is Ebuka Egbunine, from Nigeria.I studied Geology and mining.Actually i downloaded python3.5(32-bit) successfully on my laptop which operates on 32-bit memory, but the application is not opening, it displays the message " the program can't start because api-ms-crt runtime-l1-1-0.dll is missing from my computer. Try reinstalling the program to fix this problem". I have reinstalled it twice all to no avail. I want to know if there is any other possible solution to the problem. Thanks -- https://mail.python.org/mailman/listinfo/python-list
Newbie: Check first two non-whitespace characters
I need to check a string over which I have no control for the first 2 non-white
space characters (which should be '[{').
The string would ideally be: '[{...' but could also be something like
' [ { '.
Best to use re and how? Something else?
--
https://mail.python.org/mailman/listinfo/python-list
Re: Newbie: Check first two non-whitespace characters
On 2015-12-31 18:18, [email protected] wrote: I need to check a string over which I have no control for the first 2 non-white space characters (which should be '[{'). The string would ideally be: '[{...' but could also be something like ' [ { '. Best to use re and how? Something else? I would use .split and then ''.join: >>> ''.join(' [ { '.split()) '[{' It might be faster if you provide a maximum for the number of splits: >>> ''.join(' [ { '.split(None, 1)) '[{ ' -- https://mail.python.org/mailman/listinfo/python-list
Re: Newbie: Check first two non-whitespace characters
On 31/12/2015 19:18, [email protected] wrote: I need to check a string over which I have no control for the first 2 non-white space characters (which should be '[{'). The string would ideally be: '[{...' but could also be something like ' [ { '. Best to use re and how? Something else? Use pyparsing it is straight forward: >>> from pyparsing import Suppress, restOfLine >>> mystring = Suppress('[') + Suppress('{') + restOfLine >>> result = mystring.parse(' [ { I am learning pyparsing' ) >>> print result.asList() [' I am learning pyparsing'] You'll get your string inside the list. Hope this help see pyparsing doc for in depth study. Karim -- https://mail.python.org/mailman/listinfo/python-list
Re: Complain
On 12/31/2015 11:24 AM, ebuka ogbonnaya wrote: my name is Ebuka Egbunine, from Nigeria.I studied Geology and mining.Actually i downloaded python3.5(32-bit) successfully on my laptop which operates on 32-bit memory, but the application is not opening, it displays the message " the program can't start because api-ms-crt runtime-l1-1-0.dll is missing from my computer. Try reinstalling the program to fix this problem". I have reinstalled it twice all to no avail. I want to know if there is any other possible solution to the problem. Thanks Is your operating system Windows XP? If so, you won't be able to use Python 3.5 because it isn't compatible with WinXP, but you can use Python 2.7 or 3.4 instead. -- https://mail.python.org/mailman/listinfo/python-list
Re: Complain
On 31/12/2015 16:24, ebuka ogbonnaya wrote: my name is Ebuka Egbunine, from Nigeria.I studied Geology and mining.Actually i downloaded python3.5(32-bit) successfully on my laptop which operates on 32-bit memory, but the application is not opening, it displays the message " the program can't start because api-ms-crt runtime-l1-1-0.dll is missing from my computer. Try reinstalling the program to fix this problem". I have reinstalled it twice all to no avail. I want to know if there is any other possible solution to the problem. Thanks This has been asked and answered repeatedly so I suggest you search the archives. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Newbie: Check first two non-whitespace characters
On 31/12/2015 19:54, Karim wrote: On 31/12/2015 19:18, [email protected] wrote: I need to check a string over which I have no control for the first 2 non-white space characters (which should be '[{'). The string would ideally be: '[{...' but could also be something like ' [ { '. Best to use re and how? Something else? Use pyparsing it is straight forward: >>> from pyparsing import Suppress, restOfLine >>> mystring = Suppress('[') + Suppress('{') + restOfLine >>> result = mystring.parse(' [ { I am learning pyparsing' ) >>> print result.asList() [' I am learning pyparsing'] You'll get your string inside the list. Hope this help see pyparsing doc for in depth study. Karim Sorry the method to parse a string is parseString not parse, please replace by this line: >>> result = mystring.parseString(' [ { I am learning pyparsing' ) Regards -- https://mail.python.org/mailman/listinfo/python-list
Re: Newbie: Check first two non-whitespace characters
Thanks much to both of you! On Thursday, December 31, 2015 at 11:05:26 AM UTC-8, Karim wrote: > On 31/12/2015 19:54, Karim wrote: > > > > > > On 31/12/2015 19:18, [email protected] wrote: > >> I need to check a string over which I have no control for the first 2 > >> non-white space characters (which should be '[{'). > >> > >> The string would ideally be: '[{...' but could also be something like > >> ' [ { '. > >> > >> Best to use re and how? Something else? > > > > Use pyparsing it is straight forward: > > > > >>> from pyparsing import Suppress, restOfLine > > > > >>> mystring = Suppress('[') + Suppress('{') + restOfLine > > > > >>> result = mystring.parse(' [ { I am learning pyparsing' ) > > > > >>> print result.asList() > > > > [' I am learning pyparsing'] > > > > You'll get your string inside the list. > > > > Hope this help see pyparsing doc for in depth study. > > > > Karim > > Sorry the method to parse a string is parseString not parse, please > replace by this line: > > >>> result = mystring.parseString(' [ { I am learning pyparsing' ) > > Regards -- https://mail.python.org/mailman/listinfo/python-list
Re: Complain
On Thu, 31 Dec 2015 08:24:15 -0800, ebuka ogbonnaya wrote: > my name is Ebuka Egbunine, from Nigeria.I studied Geology and > mining.Actually i downloaded python3.5(32-bit) successfully on my laptop > which operates on 32-bit memory, but the application is not opening, it > displays the message " the program can't start because api-ms-crt > runtime-l1-1-0.dll is missing from my computer. Try reinstalling the > program to fix this problem". I have reinstalled it twice all to no avail. > I want to know if there is any other possible solution to the > problem. Welcome to the comp.lang.pyton newsgroup. Somebody more capable than me will probably come along soon and answer your question. In the meantime, you might improve your chances of getting a useful answer by telling us what operating system you're using, and maybe something about the hardware. -- To email me, substitute nowhere->runbox, invalid->com. -- https://mail.python.org/mailman/listinfo/python-list
Re: Newbie: Check first two non-whitespace characters
I would personally use re here.
test_string = ' [{blah blah blah'
matches = re.findall(r'[^\s]', t)
result = ''.join(matches)[:2]
>> '[{'
On Thu, Dec 31, 2015 at 10:18 AM, wrote:
> I need to check a string over which I have no control for the first 2
> non-white space characters (which should be '[{').
>
> The string would ideally be: '[{...' but could also be something like
> ' [ { '.
>
> Best to use re and how? Something else?
> --
> https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: Complain
On 12/31/2015 11:24 AM, ebuka ogbonnaya wrote: my name is Ebuka Egbunine, from Nigeria.I studied Geology and mining.Actually i downloaded python3.5(32-bit) successfully on my laptop which operates on 32-bit memory, but the application is not opening, it displays the message " the program can't start because api-ms-crt runtime-l1-1-0.dll is missing from my computer. Try reinstalling the program to fix this problem". I have reinstalled it twice all to no avail. I want to know if there is any other possible solution to the problem. Thanks Is your operating system Windows XP? If so, you won't be able to use Python 3.5 because it isn't compatible with WinXP, but you can use Python 2.7 or 3.4 instead. -- https://mail.python.org/mailman/listinfo/python-list
Re: raise None
Oscar Benjamin writes: > Exactly. The critical technique is looking at the traceback and > splitting it between what's your code and what's someone else's. > Hopefully you don't need to look at steves_library.py to figure out > what you did wrong. However if you do need to look at Steve's code > you're now stumped because he's hidden the actual line that raises. +1. As best I can tell, Steven is advocating a way to obscure information from the traceback, on the assumption the writer of a library knows that I don't want to see it. Given how very often such decisions make my debugging tasks needlessly difficult, I'm not seeing how that's a desirable feature. -- \ “Firmness in decision is often merely a form of stupidity. It | `\indicates an inability to think the same thing out twice.” | _o__)—Henry L. Mencken | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
[no subject]
I use window 7 (32-bit). so i dont know what else to do. please i need a solution to that -- https://mail.python.org/mailman/listinfo/python-list
Re: Where are we in the Python 3 transition?
Steven D'Aprano writes: > On Fri, 1 Jan 2016 03:12 am, Mark Lawrence wrote: > > > http://www.snarky.ca/the-stages-of-the-python-3-transition > > Nice link Mark, thanks. People sometimes ask me how much Python 2 code I'll be maintaining by the time official Python 2 support ends. I tell them I can't say, because I don't have 2020 vision. -- \ “Science shows that belief in God is not only obsolete. It is | `\also incoherent.” —Victor J. Stenger, 2001 | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Newbie: Check first two non-whitespace characters
On Thu, 31 Dec 2015 10:18:52 -0800, otaksoftspamtrap wrote:
> Best to use re and how? Something else?
Split the string on the space character and check the first two non blank
elements of the resulting list?
Maybe something similar to the following:
if [x for x in s.split(' ') if x != ''][0:3] == ['(', '(', '(']:
# string starts '((('
--
Denis McMahon, [email protected]
--
https://mail.python.org/mailman/listinfo/python-list
Re: raise None
On Fri, Jan 1, 2016 at 7:18 AM, Ben Finney wrote:
> Oscar Benjamin writes:
>
>> Exactly. The critical technique is looking at the traceback and
>> splitting it between what's your code and what's someone else's.
>> Hopefully you don't need to look at steves_library.py to figure out
>> what you did wrong. However if you do need to look at Steve's code
>> you're now stumped because he's hidden the actual line that raises.
>
> +1.
>
> As best I can tell, Steven is advocating a way to obscure information
> from the traceback, on the assumption the writer of a library knows that
> I don't want to see it.
>
> Given how very often such decisions make my debugging tasks needlessly
> difficult, I'm not seeing how that's a desirable feature.
What Steven's actually advocating is removing a difference between
Python code and native code. Compare:
>>> class Integer:
... def __add__(self, other):
... if isinstance(other, list):
... raise TypeError("unsupported operand type(s) for +:
'Integer' and 'list'")
... return 5
...
>>> 7 + []
Traceback (most recent call last):
File "", line 1, in
TypeError: unsupported operand type(s) for +: 'int' and 'list'
>>> Integer() + []
Traceback (most recent call last):
File "", line 1, in
File "", line 4, in __add__
TypeError: unsupported operand type(s) for +: 'Integer' and 'list'
The default int type is implemented in native code (C in CPython, Java
in Jython, etc). If the addition of an int and something else triggers
TypeError, the last line in the traceback is the last line of Python,
which is the caller. But since Integer is implemented in Python, it
adds another line to the traceback.
Would you advocate adding lines to the first traceback saying:
File "longobject.c", line 3008, in long_add
File "longobject.c", line 1425, in CHECK_BINOP
etc? It might be useful to someone trying to debug an extension
library (or the interpreter itself). Or if it's acceptable to omit
the "uninteresting internals" from tracebacks, then why can't we
declare that some bits of Python code are uninteresting, too?
We already have the means of throwing exceptions into generators,
which "pretends" that the exception happened at that point. Why can't
we throw an exception out to the caller?
I think it's a perfectly reasonable idea, albeit only a small benefit
(and thus not worth heaps of new syntax or anything).
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Newbie: Check first two non-whitespace characters
On 31/12/2015 18:54, Karim wrote: On 31/12/2015 19:18, [email protected] wrote: I need to check a string over which I have no control for the first 2 non-white space characters (which should be '[{'). The string would ideally be: '[{...' but could also be something like ' [ { '. Best to use re and how? Something else? Use pyparsing it is straight forward: >>> from pyparsing import Suppress, restOfLine >>> mystring = Suppress('[') + Suppress('{') + restOfLine >>> result = mystring.parse(' [ { I am learning pyparsing' ) >>> print result.asList() [' I am learning pyparsing'] You'll get your string inside the list. Hope this help see pyparsing doc for in depth study. Karim Congratulations for writing up one of the most overengineered pile of cobblers I've ever seen. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: raise None
Chris Angelico writes: > On Fri, Jan 1, 2016 at 7:18 AM, Ben Finney wrote: > > Given how very often such decisions make my debugging tasks > > needlessly difficult, I'm not seeing how that's a desirable feature. > > What Steven's actually advocating is removing a difference between > Python code and native code. Sure, but his proposal is to move in the direction of *less* debugging information. If I could have the traceback continue into the C code and tell me the line of C code that raised the exception, *that's* what I'd choose. The debugging information barrier of the C–Python boundary is a practical limitation, not a desirable one. I think those barriers should be as few as possible, and don't agree with enabling more of them. -- \ “Welchen Teil von ‘Gestalt’ verstehen Sie nicht? [What part of | `\‘gestalt’ don't you understand?]” —Karsten M. Self | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: raise None
On 31/12/2015 23:27, Ben Finney wrote: Chris Angelico writes: On Fri, Jan 1, 2016 at 7:18 AM, Ben Finney wrote: Given how very often such decisions make my debugging tasks needlessly difficult, I'm not seeing how that's a desirable feature. What Steven's actually advocating is removing a difference between Python code and native code. Sure, but his proposal is to move in the direction of *less* debugging information. If I could have the traceback continue into the C code and tell me the line of C code that raised the exception, *that's* what I'd choose. The debugging information barrier of the C–Python boundary is a practical limitation, not a desirable one. I think those barriers should be as few as possible, and don't agree with enabling more of them. Where did C code enter into this? What do the non C implementations do? All I see is a dumb original suggestion that should be shot down in flames as I see no merit in it at all. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: raise None
On Fri, Jan 1, 2016 at 10:27 AM, Ben Finney wrote: > Chris Angelico writes: > >> On Fri, Jan 1, 2016 at 7:18 AM, Ben Finney >> wrote: >> > Given how very often such decisions make my debugging tasks >> > needlessly difficult, I'm not seeing how that's a desirable feature. >> >> What Steven's actually advocating is removing a difference between >> Python code and native code. > > Sure, but his proposal is to move in the direction of *less* debugging > information. > > If I could have the traceback continue into the C code and tell me the > line of C code that raised the exception, *that's* what I'd choose. > > The debugging information barrier of the C–Python boundary is a > practical limitation, not a desirable one. I think those barriers should > be as few as possible, and don't agree with enabling more of them. Hmm, maybe. Personally, I wouldn't find exception tracebacks any more helpful for including a bunch of C code lines, but maybe that should be something for tooling. Actually, that's a possibility. If your traceback automatically highlights the last line that isn't imported from sys.path, that might cover the issue. Normally the error will be in your code, not some library you imported. Everything that you got from "someone else" is likely to be installed into sys.path somewhere. Might not be perfect, but it'd be a start. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: raise None
On Fri, Jan 1, 2016 at 10:36 AM, Mark Lawrence wrote: > On 31/12/2015 23:27, Ben Finney wrote: >> >> Chris Angelico writes: >> >>> On Fri, Jan 1, 2016 at 7:18 AM, Ben Finney >>> wrote: Given how very often such decisions make my debugging tasks needlessly difficult, I'm not seeing how that's a desirable feature. >>> >>> >>> What Steven's actually advocating is removing a difference between >>> Python code and native code. >> >> >> Sure, but his proposal is to move in the direction of *less* debugging >> information. >> >> If I could have the traceback continue into the C code and tell me the >> line of C code that raised the exception, *that's* what I'd choose. >> >> The debugging information barrier of the C–Python boundary is a >> practical limitation, not a desirable one. I think those barriers should >> be as few as possible, and don't agree with enabling more of them. >> > > Where did C code enter into this? What do the non C implementations do? > All I see is a dumb original suggestion that should be shot down in flames > as I see no merit in it at all. I used the term "native code", because Jython and PyPy do the exact same thing that CPython does. (I haven't checked any others than those, but I wouldn't be surprised if they, too, had this distinction.) Short-handing to "C code" is close enough. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: raise None
Ben Finney : > Chris Angelico writes: >> What Steven's actually advocating is removing a difference between >> Python code and native code. > > Sure, but his proposal is to move in the direction of *less* debugging > information. > > If I could have the traceback continue into the C code and tell me the > line of C code that raised the exception, *that's* what I'd choose. > > The debugging information barrier of the C–Python boundary is a > practical limitation, not a desirable one. I think those barriers > should be as few as possible, and don't agree with enabling more of > them. I think I agree with you. Don't check anything; let it crash and burn if the input spec is violated. Marko -- https://mail.python.org/mailman/listinfo/python-list
Happy New Year
Happy New Year to everybody on those lists. Let this year brings us a lot of happiness and joy. Lets keep the train rolling and make the upcoming year better. -- https://mail.python.org/mailman/listinfo/python-list
Re: Newbie: Check first two non-whitespace characters
On Fri, 1 Jan 2016 10:25 am, Mark Lawrence wrote: > Congratulations for writing up one of the most overengineered pile of > cobblers I've ever seen. You should get out more. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Newbie: Check first two non-whitespace characters
On Fri, 1 Jan 2016 05:18 am, [email protected] wrote: > I need to check a string over which I have no control for the first 2 > non-white space characters (which should be '[{'). > > The string would ideally be: '[{...' but could also be something like > ' [ { '. > > Best to use re and how? Something else? This should work, and be very fast, for moderately-sized strings: def starts_with_brackets(the_string): the_string = the_string.replace(" ", "") return the_string.startswith("[}") It might be a bit slow for huge strings (tens of millions of characters), but for short strings it will be fine. Alternatively, use a regex: import re regex = re.compile(r' *\[ *\{') if regex.match(the_string): print("string starts with [{ as expected") else: raise ValueError("invalid string") This will probably be slower for small strings, but faster for HUGE strings (tens of millions of characters). But I expect it will be fast enough. It is simple enough to skip tabs as well as spaces. Easiest way is to match on any whitespace: regex = re.compile(r'\w*\[\w*\{') -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Newbie: Check first two non-whitespace characters
[email protected] writes: > I need to check a string over which I have no control for the first 2 > non-white space characters (which should be '[{'). > > The string would ideally be: '[{...' but could also be something like > ' [ { '. > > Best to use re and how? Something else? Is it an arbitrary string, or is it a JSON object consisting of a list whose first element is a dictionary? Because if you're planning on reading it as a JSON object later you could just validate the types after you've parsed it. -- https://mail.python.org/mailman/listinfo/python-list
Re: Where are we in the Python 3 transition?
On 31/12/2015 16:12, Mark Lawrence wrote: "Or, how the Kübler-Ross model aptly applies to Python 3". http://www.snarky.ca/the-stages-of-the-python-3-transition I thought I had a need for asyncio and that means Python3. So I started converting some web facing apps to Python3 for practice and it wasn't that hard. I've not written anything new in Python2 for about 9 months now. I never did need asyncio in the end but the thought I might pushed me to change. YMMV -- https://mail.python.org/mailman/listinfo/python-list
Re: Happy New Year
On Fri, 1 Jan 2016 12:06 pm, Igor Korot wrote: > Happy New Year to everybody on those lists. Let this year brings us a > lot of happiness and joy. > Lets keep the train rolling and make the upcoming year better. Thanks Igor! To lurkers and contributors, newbies and experts, and even the more entertaining of our cranks (not mentioning any names, but we know who they are...), may 2016 be a better year than 2015 for us all. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re:
Please provide a few more clues about the problem. What is the problem? On Thu, Dec 31, 2015 at 1:05 PM, ebuka ogbonnaya wrote: > I use window 7 (32-bit). so i dont know what else to do. please i need a > solution to that > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Newbie: Check first two non-whitespace characters
On 31Dec2015 18:38, MRAB wrote: On 2015-12-31 18:18, [email protected] wrote: I need to check a string over which I have no control for the first 2 non-white space characters (which should be '[{'). The string would ideally be: '[{...' but could also be something like ' [ { '. Best to use re and how? Something else? I would use .split and then ''.join: ''.join(' [ { '.split()) '[{' This presumes it is ok to drop/mangle/lose the whitespace elsewhere in the string. If it contains quoted text I'd expect that to be very bad. It might be faster if you provide a maximum for the number of splits: ''.join(' [ { '.split(None, 1)) '[{ ' Not to mention safer. I would use lstrip and startswith: s = lstrip(s) if s.startswith('['): s = s[1:].lstrip() if s.startswith('{'): ... deal with s[1:] here ... It is wordier, but far more basic and direct. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: Converting py files to .exe and .dmg
On Tuesday, 29 December 2015 01:09:30 UTC+9, Adam M wrote: > On Monday, December 28, 2015 at 10:35:41 AM UTC-5, Brian Simms wrote: > > Hi there, > > > > I have done a lot of looking around online to find out how to convert > > Python files to .exe and .dmg files, but I am confused. Could someone > > provide pointers/advice as to how I can turn a Python file into a Windows > > .exe and Mac .dmg file. > > > > Thanks for any help. > > Please check this website: > http://www.pyinstaller.org/ > It should solve your problem. Hi Adam M, I went to www.pyinstaller.org and downloaded the software. I don;t know if you are using Windows or Mac. I have a Mac and when I go into Terminal to run "setup.py install" I keep getting "-bash: command not found". I have read the manual and done what it suggested, but still no joy. I have MacPorts (which I downloaded several days ago. If you could provide any pointers as to how I could run the "setup.py" on my Mac, it would be hugely appreciated. Thanks. :-) -- https://mail.python.org/mailman/listinfo/python-list
