[ANN] Leipzig Python User Group - Meeting, June 14, 2011, 08:00pm
=== Leipzig Python User Group === We will meet on Tuesday, June 14 at 8:00 pm at the training center of Python Academy in Leipzig, Germany ( http://www.python-academy.com/center/find.html ). Andreas Bunkahle will give a talk about OpenCV and Python. OpenCV (CV = Computer Vision) and Python OpenCV is a very powerful and fast image processing and computer vision library. The combination of OpenCV 2.1 and Python 2.6 is stable and works reliably. Features include face and pattern recognition, web cam control, and morphing among many others. Everybody who uses Python, plans to do so or is interested in learning more about the language is encouraged to participate. While the meeting language will be mainly German, we will provide English translation if needed. Food and soft drinks are provided. Please send a short confirmation mail to i...@python-academy.de, so we can prepare appropriately. Current information about the meetings are at http://www.python-academy.com/user-group . Mike == Leipzig Python User Group === Wir treffen uns am Dienstag, 14.06.2011 um 20:00 Uhr im Schulungszentrum der Python Academy in Leipzig ( http://www.python-academy.de/Schulungszentrum/anfahrt.html ). Andreas Bunkahle wird einen Vortrag über OpenCV und Python halten. OpenCV (CV = Computer Vision) und Python OpenCV ist eine sehr mächtige und schnelle Bibliothek für die Bildverarbeitung und maschinelles Sehen, die in der Version 2.1 mit Python 2.6 recht stabil und zuverlässig läuft. Gesichts- und Mustererkennung, Webcam-Ansteuerung und Morphing sind nur einige von vielen Möglichkeiten die die OpenCV bietet. Willkommen ist jeder, der Interesse an Python hat, die Sprache bereits nutzt oder nutzen möchte. Für das leibliche Wohl wird gesorgt. Eine Anmeldung unter i...@python-academy.de wäre nett, damit wir genug Essen besorgen können. Aktuelle Informationen zu den Treffen sind unter http://www.python-academy.de/User-Group zu finden. Viele Grüße Mike -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
ANN: cssutils 0.9.8a2
what is it -- A Python package to parse and build CSS Cascading Style Sheets. (Not a renderer though!) about this release -- 0.9.8a2 is a bugfix release. Compatibility to Python 3.x is currently in development. At the same time Python 2.4 and Python 2.5 compatibility will probably be lost... 0.9.8 will be the last version to support Python 2.4 and Python 2.5. main changes - BUGFIX: Fixed Issue #59 which showed a rather strange problem with longer space separated lists of font-family values being so slow to actually stop parsing. - BUGFIX/IMPROVEMENT: Fixed Issue #48. ``CSSParser.parseUrl()`` uses the defined fetcher of this parser *for the initial stylesheet* at url too and not just the imported sheets *from* this sheet. - BUGFIX: Fixed Issue #50 which prevented cssutils parsing the acid2.css file correctly. Problem were selectors starting directly with ``[class]`` (an attribute selector). + **API CHANGE (major)** (Known) named colors are parsed as ColorValue objects now. These are the 16 simple colors (black, white, etc) and `transparent` but not all Extended color keywords yet. Also changed ``ColorValue.type`` to ``Value.COLOR_VALUE``. ColorValue has additional properties ``red, green, blue, alpha`` and ``colorType`` which is one of IDENT, HASH or FUNCTION for now. + API CHANGE (minor) Removed already DEPRECATED ``cssutils.parse`` and ``CSSParser.parse``. Use the more specific functions/methods ``parseFile parseString parseUrl`` instead. Removed already DEPRECATED ``cssutils.log.setlog`` and ``.setloglevel``. Use ``.setLog`` and ``.setLevel`` instead. Removed already DEPRECATED ``cssutils.ser.keepUnkownAtRules`` (note the typo). Use ``.keepUnknownAtRules`` instead. - IMPROVEMENT: Added validation profiles for some properties from `CSS Backgrounds and Borders Module Level 3 http://www.w3.org/TR/css3-background/`__, `CSS3 Basic User Interface Module http://www.w3.org/TR/css3-ui/#resize`__, `CSS Text Level 3 http://www.w3.org/TR/css3-text/`__ mainly `cursor`, `outline`, `resize`, `box-shadow`, `text-shadow` license --- cssutils is published under the LGPL version 3 or later, see http://cthedot.de/cssutils/ If you have other licensing needs please let me know. download For download options see http://cthedot.de/cssutils/ cssutils needs Python 2.4 and higher or Jython 2.5 and higher (tested with Python 2.7.1(x64), 2.6.5(x64), 2.5.4(x32), 2.4.4(x32) and Jython 2.5.1 on Win7x64 only) Bug reports (via Google code), comments, etc are very much appreciated! Thanks. Christof -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
Keyboard Layout: Dvorak vs Colemak: is it Worthwhile to Improve the Dvorak Layout?
(a lil weekend distraction from comp lang!) in recent years, there came this Colemak layout. The guy who created it, Colemak, has a site, and aggressively market his layout. It's in linuxes distro by default, and has become somewhat popular. I remember first discovering it perhaps in 2007. Me, being a Dvorak typist since 1994, am curious on what he has to say about comparison. I recall, i was offended seeing how he paints a bias in peddling his creation. So, here, let me repaint his bias. Here it is, and judge for yourself. 〈Keyboard Layout: Dvorak vs Colemak: is it Worthwhile to Improve the Dvorak Layout?〉 http://xahlee.org/kbd/dvorak_vs_colemak.html here's a interesting excerpt: Just How Much Do You Type? Many programers all claim to type 8 or 10 hours a day. They may be sitting in front of the computer all day, but the time their fingers actually dance on keyboard is probably less than 1 hour per day. Contrast data-entry clerks. They are the real typists. Their fingers actually type, continuously, for perhaps 6 hours per day. It is important get a sense of how much you actually type. This you can do by logging you keystrokes using a software. Let's assume a pro typist sustain at 60 wpm. 60 wpm is 300 strokes per min, or 18k per hour. Suppose she works 8 hours a day, and assume just 3 hours actually typing. 18k × 3 = 54k chars per day. With this figure, you can get a sense of how many “hours” you actually type per day. I sit in front of computer on average 13 hours per day for the past several years. I program and write several blogs. My actual typing is probably double or triple of average day-job programers. From my emacs command frequency log for 6 months in 2008, it seems i only type 17k strokes per day. That's 31% of the data-entry clerk scenario above. Or, i only type ONE hour a day! I was quite surprised how low my own figure is. But thinking about it… it make sense. Even we sit in front of computer all day, but the actual typing is probably some miniscule percentage of that. Most of the time, you have to chat, lunch, run errands, browse web, read docs, run to the bathroom. Perhaps only half of your work time is active coding or writing (emails; docs). Of that duration, perhaps majority of time you are digesting the info on screen. Your whole day's typing probably can be done in less than 20 minutes if you just type continuously. If your typing doesn't come anywhere close to a data-entry clerk, then any layout “more efficient” than Dvorak is practically meaningless. Xah -- http://mail.python.org/mailman/listinfo/python-list
Re: (*args **kwargs) how do I use' em?
A good tutorial will surely help : http://www.saltycrane.com/blog/2008/01/how-to-use-args-and-kwargs-in-python/ The idea between *args and *kwargs is to create function (callables) which accepts an arbitrary number of anonymous and/or keyword arguments. It's useful when you want to create a function that will call an another one (inheritances or decorators). Hope this helps, -- Envoyé avec Sparrow (http://www.sparrowmailapp.com/?sig) Le samedi 11 juin 2011 à 07:01, TheSaint a écrit : Hello, I'm seldomly writng python code, nothing but a beginner code. I wrote these lines = _log_in= mhandler.ConnectHandler(lmbox, _logger, accs) multhr= sttng['multithread'] if multhr: _log_in= mhandler.mThreadSession(lmbox, _logger, accs) for svr in servrs: nmsvr, user, pwd, ptcl = servrs[svr] al, dn= sttng['Cfilter']; er= sttng['filter'] try: rx.append( _log_in.connect((nmsvr, user, pwd, ptcl, (al, dn, er except ProtocolError: print(svr+ errors['SerProb']) except KeyboardInterrupt: raise SystemExit(errors['YouStop']) if multhr: for s in rx: try: s.start() except (ProtocolError, AttributeError): print(svr+ errors['SerProb']) except KeyboardInterrupt: raise SystemExit(errors['YouStop']) for s in rx: try: s.join() # waiting all threads to finish except (ProtocolError, AttributeError): print(svr+ errors['SerProb']) except KeyboardInterrupt: raise SystemExit(errors['YouStop']) = Surely ugly and I believe that would be a better way to pass the arguments as I mention on the subject. Then it should give a dictionary of keywords and some function or a callable. I don't know how to put down these code lines. I think I should restructure many points of my data. Any suggestion will make me happier :) -- goto /dev/null -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: (*args **kwargs) how do I use' em?
On 11 juin, 07:01, TheSaint nob...@nowhere.net.no wrote: Hello, I'm seldomly writng python code, nothing but a beginner code. I wrote these lines = _log_in= mhandler.ConnectHandler(lmbox, _logger, accs) multhr= sttng['multithread'] if multhr: _log_in= mhandler.mThreadSession(lmbox, _logger, accs) for svr in servrs: nmsvr, user, pwd, ptcl = servrs[svr] al, dn= sttng['Cfilter']; er= sttng['filter'] try: rx.append( _log_in.connect((nmsvr, user, pwd, ptcl, (al, dn, er except ProtocolError: print(svr+ errors['SerProb']) except KeyboardInterrupt: raise SystemExit(errors['YouStop']) if multhr: for s in rx: try: s.start() except (ProtocolError, AttributeError): print(svr+ errors['SerProb']) except KeyboardInterrupt: raise SystemExit(errors['YouStop']) for s in rx: try: s.join() # waiting all threads to finish except (ProtocolError, AttributeError): print(svr+ errors['SerProb']) except KeyboardInterrupt: raise SystemExit(errors['YouStop']) = Surely ugly and I believe that would be a better way to pass the arguments as I mention on the subject. Then it should give a dictionary of keywords and some function or a callable. I don't know how to put down these code lines. I think I should restructure many points of my data. Any suggestion will make me happier :) -- goto /dev/null could you check the Alex Martelli comments here ? maybe some clarification about kwargs... http://stackoverflow.com/questions/1098549/proper-way-to-use-kwargs-in-python OliDa -- http://mail.python.org/mailman/listinfo/python-list
Square bracket and dot notations?
Hi all,
I am beginner in Python. What is interesting for me is that Python
interpreter treats in different way dot and square bracket notations.
I am coming from JavaScript where both notations lead prototype chain
lookup.
In Python it seems square bracket and dot notations lead lookup in
different store.
Simple example with dict object:
d = {key : value}
print d[key] #value
print d.key #AttributeError
I found an implementation of dict which uses both notations for its
keys lookup, which I think is stupid idea when obviously both
notations lead different lookup. It will confuse me as a reader of the
code.
Anyway, I would like to know more about the lookup for key of dict and
lookup for property of any object with dot notation. Any materials and
explanations are highly appreciated.
--
http://mail.python.org/mailman/listinfo/python-list
Overcharged
I mad a call last night and never even talked to anybody, I knew I was being charged to just look and I'm ok with that amount u was charged. There was another charge though of I think 26 dollers witch I was not told or warned about at all, I need to know who I can call and talk to about this Sent from my Samsung Epic™ 4G -- http://mail.python.org/mailman/listinfo/python-list
Re: Square bracket and dot notations?
On 2011.06.11 04:41 AM, Asen Bozhilov wrote:
Hi all,
I am beginner in Python. What is interesting for me is that Python
interpreter treats in different way dot and square bracket notations.
I am coming from JavaScript where both notations lead prototype chain
lookup.
In Python it seems square bracket and dot notations lead lookup in
different store.
Simple example with dict object:
d = {key : value}
print d[key] #value
print d.key #AttributeError
d is this case is a dictionary object, and therefore has keys you can
look up (with square brackets). The same is true with lists and tuples
(which have integers as keys). An arbitrary object can have arbitrary
values in arbitrary variables in its namespace (accessed with dots).
Objects can have a __dict__ variable that stores the variables in their
namespace as a dictionary (not entirely sure how this works; I'm sure
someone can expand on it).
With:
class simpleObject():
pass
a = simpleObject()
This:
a.key = 'value'
a.otherkey = 'othervalue'
I simpler than:
a.props = {}
a.props['key'] = 'value'
a.props['otherkey'] = 'othervalue'
However, if you want your object to hold several different sets of keys
and respective values, dictionaries (or lists/tuples) make more sense.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Square bracket and dot notations?
Asen Bozhilov asen.bozhi...@gmail.com writes: I am beginner in Python. What is interesting for me is that Python interpreter treats in different way dot and square bracket notations. I am coming from JavaScript where both notations lead prototype chain lookup. Run, don't walk, to the Python Tutorial. Work through each section, do the examples, experiement to get an understanding of the examples, and then continue. URL:http://docs.python.org/tutorial/ In Python it seems square bracket and dot notations lead lookup in different store. That's right. Square bracket syntax accesses an object's items, dot syntax accesses an object's attributes. Anyway, I would like to know more about the lookup for key of dict and lookup for property of any object with dot notation. Any materials and explanations are highly appreciated. Work through the tutorial from beginning to end to get a good grounding in this and other fundamentals. Welcome to the language, and enjoy your learning! -- \“Most people, I think, don't even know what a rootkit is, so | `\ why should they care about it?” —Thomas Hesse, Sony BMG, 2006 | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Overcharged
Ethan eman77...@gmail.com writes: I mad a call last night and never even talked to anybody, Sent from my Samsung Epic™ 4G Your Epic 4G must not have been programmed in Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: Square bracket and dot notations?
On 11 Giu, 11:41, Asen Bozhilov asen.bozhi...@gmail.com wrote:
Hi all,
I am beginner in Python. What is interesting for me is that Python
interpreter treats in different way dot and square bracket notations.
I am coming from JavaScript where both notations lead prototype chain
lookup.
In Python it seems square bracket and dot notations lead lookup in
different store.
Simple example with dict object:
d = {key : value}
print d[key] #value
print d.key #AttributeError
I found an implementation of dict which uses both notations for its
keys lookup, which I think is stupid idea when obviously both
notations lead different lookup. It will confuse me as a reader of the
code.
Anyway, I would like to know more about the lookup for key of dict and
lookup for property of any object with dot notation. Any materials and
explanations are highly appreciated.
Since python is not javascript ( duh :-), [] and . notations are used
for different purposes and, although
they share some commonalities as I try to show later in this post,
they should not be intermixed without
a very good reeason ( and it's cool is not a good reason IMO).
Broadly speaking, square brackets are used to access element in array,
dict, tuples and sequences.
The dot nootation is used to get the attributes and methods of
instances.
User classes - that is the ones you define with the class statement -
can implement support for the squared bracket and
dot notations:
- the expression myinstance[index] is sort of translated into of
myinstance.__getitem__(index)
- the expression myinstance.myattribute is sort of translated of
myinstance.__getattr__(myattribute)
Classes also exposes a __dict__ attributes that allows to access to
instance attributes and methods using dictionary
semantics. That is, myistance.__dict__[myattribute] should give the
same result as myinstance.myattribute.
I believe this is because in the beginning class instances actually
had a dictionary storing the instance attributes.
Nowadays it is more complex than that, I think, but the interface is
kept to allow dynamic access to instance contents,
although the reccomended way to do it this is getattr(myinstance,
myattribute). Of course it is only useful to use __dict__
or getattr when the parameter is not a constant string but a variable
referring to a string computed at run time ( this is
what I mean for 'dynamic access' ).
HTH.
Ciao
FB
--
http://mail.python.org/mailman/listinfo/python-list
Re: (*args **kwargs) how do I use' em?
OliDa wrote: maybe some clarification about kwargs... http://stackoverflow.com/questions/1098549/proper-way-to-use-kwargs-in- python Great point. Now it's clearer :) I think I'll share the dictionary which contains the configuration loaded form a file. -- goto /dev/null -- http://mail.python.org/mailman/listinfo/python-list
Re: Recursion error in metaclass
On Sat, 11 Jun 2011 01:33:25 -0400, Terry Reedy wrote:
On 6/10/2011 11:34 PM, Steven D'Aprano wrote:
I have a metaclass in Python 3.1:
class MC1(type):
@staticmethod
def get_mro(bases):
print('get_mro called')
return type('K', bases, {}).__mro__[1:]
The call to type figures out the proper metaclass from bases and
forwards the call to that (or to its __new__ method).
[...]
Since uou do not pass dict to get_mro. it passes {} to type and MC1 and
the test for docstring fails and the loop is broken and the empty class
is discarded after getting its mro.
Thanks for the explanation. You confused me for a while talking about
MC1, because that's the metaclass that *doesn't* raise an exception, but
I think I see the issue now.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: uhmm... your chance to spit on me
On Jun 11, 5:36 am, Jim Burton j...@sdf-eu.org wrote: Xah Lee xah...@gmail.com writes: Dear lisp comrades, it's Friday! The answers to your question give poor coverage of the possible responses to your writing. I myself enjoy reading what you write, most of the time, but become bored +1 on the 'poor coverage' -- eg I find your unicode pages useful. As to the form of your writings -- I am one of those who finds a RTFM answer less rude and more helpful than no answer (as long as a FM is also indicated). As to you as a person, I guess depression is an epidemic among computer geekers. For me the magic medicine is to see and soak in the sun in the morning. Try it for 5 days and see if your outlook on life does not sweeten up. -- http://mail.python.org/mailman/listinfo/python-list
Python Card alternatives?
Desktop apps don't seem to be the wave of the future, but they still serve a useful purpose today. They can be ideal for a quick database table management screen, or a data entry front end for a program with a bunch of parameters. It's not easy enough to build a quick utility with a GUI front end, though. Wax and PythonCard (and maybe others) tried to hit that niche, but development on both is spotty at best. Some claim that Dabo's gui builder is a good one for this purpose, and maybe it can be. Are there any other, better solutions? I've been looking at Rebol lately, and it has some points of interest. I much prefer Python as a language, but Rebol View's layout specifications are wonderfully concise, and the support code seems to be fairly straightforward as well. Has anyone tried to mimic their approach in Python? -- rzed -- http://mail.python.org/mailman/listinfo/python-list
Re: Square bracket and dot notations?
Francesco Bochicchio wrote:
User classes - that is the ones you define with the class statement -
can implement support for the squared bracket and
dot notations:
- the expression myinstance[index] is sort of translated into of
myinstance.__getitem__(index)
- the expression myinstance.myattribute is sort of translated of
myinstance.__getattr__(myattribute)
It is exactly what I wanted to know. Thank you. I have not examined
classes in Python yet, but when I do it I will understand some new
things. One of the most interesting is, can an object inherit items
trough the parent class? By items I mean items which are accessible
trough square bracket notation.
I really like Pythonic way here. Square bracket and dot notations
allow me to create an object which can be true hash map and
meanwhile to support independent methods from its keys. I could have
an item and a property with same names and they won't interfere each
other.
Classes also exposes a __dict__ attributes that allows to access to
instance attributes and methods using dictionary
semantics. That is, myistance.__dict__[myattribute] should give the
same result as myinstance.myattribute.
I believe this is because in the beginning class instances actually
had a dictionary storing the instance attributes.
Nowadays it is more complex than that, I think, but the interface is
kept to allow dynamic access to instance contents,
although the reccomended way to do it this is getattr(myinstance,
myattribute). Of course it is only useful to use __dict__
or getattr when the parameter is not a constant string but a variable
referring to a string computed at run time ( this is
what I mean for 'dynamic access' ).
Yeah, I agree with that. For example in JS exactly square bracket
notation has been invented to dynamic property access. The biggest
question here is why do you need dynamic property access? In language
as JavaScript which is strongly bounded to browser environment, you
could use:
function getForm(formName) {
return document.forms[formName];
}
Another use case is to call a method of object and kept the proper
`this' value. E.g.
obj.x = 10;
obj.method = function () {
return this.x;
};
function callMethod(obj, method) {
return obj[method]();
}
callMethod(obj, 'method'); //10
Of course it could be achieved in different ways and with dot notation
of course.
Thank you very much for the answer.
--
http://mail.python.org/mailman/listinfo/python-list
Re: parallel computations: subprocess.Popen(...).communicate()[0] does not work with multiprocessing.Pool
Greetings, cmd1 = /usr/local/bin/matlab ... myMatlab.1.m subprocess.Popen([cmd1], shell=True, stdout=subprocess.PIPE).communicate()[0] Try a list of arguments as the command to run. subprocess.Popen([/usr/local/bin/matlab, ... myMatlab.l.m] ...) If you can switch to 2.7, you'll be to use check_output (http://docs.python.org/library/subprocess.html#subprocess.check_output) HTH -- Miki Tebeka miki.teb...@gmail.com http://pythonwise.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Card alternatives?
As you said, desktop apps are losing appeal. I suggest looking for a web based solution. Perhaps python + silverlight? (I haven't tried it though). Unfortunately, the client-side (browser) is the domain of javascript. What I'm doing is polishing my html/css skills coupled with jquery. I have lost faith in a python solution for these tasks. Although there's something close enough that can make your experience totally different: Coffeescript. This is an enhanced syntax layer on top of javascript, inspired in python and ruby, which feels like a breath of fresh air to any python or ruby programmer. It plays very well with jquery and gives you all the pythonic goodies you are used to, like list comprehensions (called array and object comprehensions), slicing, ranges, etc. Coffeescript pre compiles your code to pure javascript so there's no performance degradation at all. If it does not convince you and you still prefer a python solution, you may want to check pyjamas (a port of GWT to python). There are also some experiments such as Skulp to have python running in the browser, although this approach implies a serious performance hit, since it's a full python implementation in javascript. regards, Luis -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Card alternatives?
Luis, Not the OP, but thank you for passing on the CoffeeScript recommendation - looks very interesting!! http://jashkenas.github.com/coffee-script/ Regards, Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Card alternatives?
* rzed rzan...@gmail.com [110611 05:14]: Desktop apps don't seem to be the wave of the future, but they still serve a useful purpose today. They can be ideal for a quick database table management screen, or a data entry front end for a program with a bunch of parameters. It's not easy enough to build a quick utility with a GUI front end, though. Wax and PythonCard (and maybe others) tried to hit that niche, but development on both is spotty at best. Some claim that Dabo's gui builder is a good one for this purpose, and maybe it can be. Are there any other, better solutions? I've been looking at Rebol lately, and it has some points of interest. I much prefer Python as a language, but Rebol View's layout specifications are wonderfully concise, and the support code seems to be fairly straightforward as well. Has anyone tried to mimic their approach in Python? I've used rebol for over 11 years. Longer than I have used python. I've not used rebol/view however, since my meal-ticket is console and web progamming. I'm guessing that you are going to find that difficult to do, but my suggestion would be: 1)Get into one of the rebol communities - probably thru altme. 2)You will find that most rebol programmers work in other languages also, and quite a few (like me) in python. 3)You are likely to get a lot of ideas there. cheers -- Tim tim at johnsons-web dot com or akwebsoft dot com http://www.akwebsoft.com -- http://mail.python.org/mailman/listinfo/python-list
How to avoid () when writing a decorator accepting optional arguments?
I've written this decorator to deprecate a function and (optionally) provide a callable as replacement def deprecated(repfun=None): A decorator which can be used to mark functions as deprecated. Optional repfun is a callable that will be called with the same args as the decorated function. def outer(fun): def inner(*args, **kwargs): msg = %s is deprecated % fun.__name__ if repfun is not None: msg += ; use %s instead % (repfun.__name__) warnings.warn(msg, category=DeprecationWarning, stacklevel=2) if repfun is not None: return repfun(*args, **kwargs) else: return fun(*args, **kwargs) return inner return outer Now, I can use my decorator as such: @deprecated() def foo(): return 0 ...or provide an optional argument: @deprecated(some_function) def foo(): return 0 ...but I don't know how to modify it so that I can omit parentheses: @deprecated def foo(): return 0 Any hint? --- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/p/psutil/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Recursion error in metaclass
On 6/11/2011 7:38 AM, Steven D'Aprano wrote:
On Sat, 11 Jun 2011 01:33:25 -0400, Terry Reedy wrote:
On 6/10/2011 11:34 PM, Steven D'Aprano wrote:
I have a metaclass in Python 3.1:
class MC1(type):
@staticmethod
def get_mro(bases):
print('get_mro called')
return type('K', bases, {}).__mro__[1:]
The call to type figures out the proper metaclass from bases and
forwards the call to that (or to its __new__ method).
[...]
Since uou do not pass dict to get_mro. it passes {} to type and MC1 and
the test for docstring fails and the loop is broken and the empty class
is discarded after getting its mro.
Thanks for the explanation. You confused me for a while talking about
MC1, because that's the metaclass that *doesn't* raise an exception, but
Sorry, you probably changed that to MC2 for the second example and I did
not notice. The point is that when either version calls get_mro and
type, types calls back to the same metaclass, so that unguarding the
call to get_mro results in looping.
I think I see the issue now.
What may not be obvious from the docs is that the metaclass calculation
described in the doc section on class statements is carried out within
type.__new__ (or after a possible patch, called from within that), so
that type calls are really a dynamic form of the class statement even
when another another metaclass is specified or implied. Return a new
type object. includes instances of type subclasses. I am not sure what
happens with metaclasses that are not type subclasses. There is at least
one bug report about the metaclass calculation, which is why I happen to
have read the typeobject.__new__ code. But I have not read the
build-class code and all the details of class creation. So I may have
some of the details above wrong.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: Square bracket and dot notations?
On 6/11/2011 10:40 AM, Asen Bozhilov wrote: It is exactly what I wanted to know. Thank you. I have not examined classes in Python yet, but when I do it I will understand some new things. One of the most interesting is, can an object inherit items trough the parent class? By items I mean items which are accessible trough square bracket notation. .attributes are inherited. [index-or-key] items are not. I really like Pythonic way here. Square bracket and dot notations allow me to create an object which can be true hash map and meanwhile to support independent methods from its keys. I could have an item and a property with same names and they won't interfere each other. Right. d.items is a dict method. d['items'] is whatever you assign. Named tuples in the collections modules, which allow access to fields through .name as well as [index], have the name class problem. All the methods are therefore given leading underscore names to avoid this. [But there still could be a clash if someone used field names with leading underscores!] Python reserves and uses __xxx__ for system names just to avoid clashes. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: How to avoid () when writing a decorator accepting optional arguments?
On Sat, Jun 11, 2011 at 1:27 PM, Giampaolo Rodolà g.rod...@gmail.com wrote: @deprecated() def foo(): return 0 This is equivalent to: foo = deprecated()(foo) @deprecated(some_function) def foo(): return 0 foo = deprecated(some_function)(foo) @deprecated def foo(): return 0 foo = deprecated(foo) You want to make the third case be equivalent to the first case. The problem is that there is no way to distinguish between deprecated(foo) (in the third case) and deprecated(some_function) in the second case. Both are receiving a single argument that is a function, but the latter needs to return a decorator while the former needs to return a decorated function. Since there is no way to distinguish the two cases by the arguments, you would need a separate decorator. You could do something like this: deprecated_default = deprecated() @deprecated_default def foo(): return 0 But this hardly seems worthwhile to me just to avoid typing an extra couple of parentheses. Cheers, Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: How to avoid () when writing a decorator accepting optional arguments?
On 6/11/2011 3:27 PM, Giampaolo Rodolà wrote: I've written this decorator to deprecate a function and (optionally) provide a callable as replacement def deprecated(repfun=None): A decorator which can be used to mark functions as deprecated. Optional repfun is a callable that will be called with the same args as the decorated function. def outer(fun): def inner(*args, **kwargs): msg = %s is deprecated % fun.__name__ if repfun is not None: msg += ; use %s instead % (repfun.__name__) warnings.warn(msg, category=DeprecationWarning, stacklevel=2) if repfun is not None: return repfun(*args, **kwargs) else: return fun(*args, **kwargs) return inner return outer Now, I can use my decorator as such: @deprecated() def foo(): return 0 ...or provide an optional argument: @deprecated(some_function) def foo(): return 0 ...but I don't know how to modify it so that I can omit parentheses: @deprecated def foo(): return 0 These are fundamentally different beasts. One makes a call to create the decorator. The other is the decorator. Write two decorators. The unparameterized version is trivial. def outer(fun): def inner(*args, **kwargs): msg = %s is deprecated % fun.__name__ warnings.warn(msg, category=DeprecationWarning, stacklevel=2) return fun(*args, **kwargs) rturn inner The parameterized version will be simpler also (with None possibility deleted). -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Emacs Python indention
Hi Emacs / Python coders, moving a region of python code for more than one indention in Emacs is quite annoying, cause the python-shift-left and -right functions always loose the mark and one has to reactivate it with \C-x \C-x or guess how many indentions one want to make and do a \C-u nr \C-c That were the only solutions I found on the net and well both are not very comfortable so here's a fix for that. With the following code you can use \C-c left and right to move your Python code to the left and to the right :) HF Basti (defun balle-python-shift-left () (interactive) (let (start end bds) (if (and transient-mark-mode mark-active) (setq start (region-beginning) end (region-end)) (progn (setq bds (bounds-of-thing-at-point 'line)) (setq start (car bds) end (cdr bds (python-shift-left start end)) (setq deactivate-mark nil) ) (defun balle-python-shift-right () (interactive) (let (start end bds) (if (and transient-mark-mode mark-active) (setq start (region-beginning) end (region-end)) (progn (setq bds (bounds-of-thing-at-point 'line)) (setq start (car bds) end (cdr bds (python-shift-right start end)) (setq deactivate-mark nil) ) (add-hook 'python-mode-hook (lambda () (define-key python-mode-map (kbd C-c right) 'balle-python-shift-right) (define-key python-mode-map (kbd C-c left) 'balle-python-shift-left) ) ) signature.asc Description: PGP signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Square bracket and dot notations?
Terry Reedy wrote: Right. d.items is a dict method. d['items'] is whatever you assign. Named tuples in the collections modules, which allow access to fields through .name as well as [index], have the name class problem. All the methods are therefore given leading underscore names to avoid this. [But there still could be a clash if someone used field names with leading underscores!] Scripting languages as JavaScript, Python and other so dynamic languages allow user to shoot in his feet. I think the developer should learning the curves of the language before start writing complex applications. That was the goal of this thread. -- http://mail.python.org/mailman/listinfo/python-list
Re: Recursion error in metaclass
On Sat, Jun 11, 2011 at 21:39, Terry Reedy tjre...@udel.edu wrote: What may not be obvious from the docs is that the metaclass calculation described in the doc section on class statements is carried out within type.__new__ (or after a possible patch, called from within that), so that type calls are really a dynamic form of the class statement even when another another metaclass is specified or implied. Return a new type object. includes instances of type subclasses. I am not sure what happens with metaclasses that are not type subclasses. There is at least one bug report about the metaclass calculation, which is why I happen to have read the typeobject.__new__ code. But I have not read the build-class code and all the details of class creation. So I may have some of the details above wrong. Just for the record, I think this is the mentioned bug: http://bugs.python.org/issue1294232 Daniel -- http://mail.python.org/mailman/listinfo/python-list
__dict__ is neato torpedo!
I'm pretty happy that I can copy variables and their value from one object's namespace to another object's namespace with the same variable names automatically: class simpleObject(): pass a = simpleObject() b = simpleObject() a.val1 = 1 a.val2 = 2 b.__dict__.update(a.__dict__) a.val1 = 'a' a.val1 'a' a.val2 2 b.val1 1 b.val2 2 The reason I'm posting this is to ask what to watch out for when doing this. I've seen vague warnings that I don't really understand, and I'm hoping someone can enlighten me. -- http://mail.python.org/mailman/listinfo/python-list
Re: __dict__ is neato torpedo!
On 6/11/2011 9:32 PM, Andrew Berg wrote: I'm pretty happy that I can copy variables and their value from one You are copying names and their associations, but not the objects or thier values. object's namespace to another object's namespace with the same variable names automatically: class simpleObject(): pass a = simpleObject() b = simpleObject() a.val1 = 1 a.val2 = 2 b.__dict__.update(a.__dict__) a.val1 = 'a' a.val1 'a' a.val2 2 b.val1 1 b.val2 2 -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: __dict__ is neato torpedo!
On Sat, 11 Jun 2011 20:32:37 -0500, Andrew Berg wrote: I'm pretty happy that I can copy variables and their value from one object's namespace to another object's namespace with the same variable names automatically: class simpleObject(): pass a = simpleObject() b = simpleObject() a.val1 = 1 a.val2 = 2 b.__dict__.update(a.__dict__) [...] The reason I'm posting this is to ask what to watch out for when doing this. I've seen vague warnings that I don't really understand, and I'm hoping someone can enlighten me. You are injecting data and code from one object to another. If you don't know what you're injecting, bad things could happen. Just like in real life :) The update method unconditionally replaces any item in the first object that matches an item in the second. If it has things you don't want, too bad, you'll get them: class K(object): ... data = things ... status = working hard for a living ... a = K() b = K() b.data = stuff and things # what you want b.status = leaching off dear old granny # but not this one a.__dict__.update(b.__dict__) print(a.status) leaching off dear old granny So never update from a random object you don't know well. A second, more subtle risk: not all objects have a __dict__. But if you obey the rule about never updating from arbitrary objects you don't know, then you won't be surprised by an object with no __dict__. Other than that, using update is a good trick to have in your toolbox. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: __dict__ is neato torpedo!
On 2011.06.11 09:12 PM, Terry Reedy wrote: On 6/11/2011 9:32 PM, Andrew Berg wrote: I'm pretty happy that I can copy variables and their value from one You are copying names and their associations, but not the objects or thier values. Associations? The update() method copies the values; a.val1 and b.val1 point to two different places in memory. -- http://mail.python.org/mailman/listinfo/python-list
Re: __dict__ is neato torpedo!
On 2011.06.11 09:13 PM, Steven D'Aprano wrote: So never update from a random object you don't know well. Of course. In the project I'm working on, this will be used in the __init__() method of a class that accepts a pair of dictionaries or possibly **kwargs (for flexibility and to avoid the very problem of an object without a __dict__). A second, more subtle risk: not all objects have a __dict__. But if you obey the rule about never updating from arbitrary objects you don't know, then you won't be surprised by an object with no __dict__. What objects don't (other than the obvious ones like strings, dictionaries, ints and lists)? -- http://mail.python.org/mailman/listinfo/python-list
Re: __dict__ is neato torpedo!
On Sat, Jun 11, 2011 at 8:21 PM, Andrew Berg bahamutzero8...@gmail.com wrote:
On 2011.06.11 09:12 PM, Terry Reedy wrote:
On 6/11/2011 9:32 PM, Andrew Berg wrote:
I'm pretty happy that I can copy variables and their value from one
You are copying names and their associations, but not the objects or
thier values.
Associations? The update() method copies the values; a.val1 and b.val1
point to two different places in memory.
Incorrect. The names in b will be bound to the same objects as the
names in a, not to copies of them. For immutable objects such as
ints, this doesn't matter. For mutable objects such as lists, it can:
class X(object):
... pass
...
a = X()
b = X()
a.foo = ['apples']
b.__dict__.update(a.__dict__)
a.foo
['apples']
b.foo
['apples']
a.foo.append('oranges')
a.foo
['apples', 'oranges']
b.foo
['apples', 'oranges']
Cheers,
Ian
--
http://mail.python.org/mailman/listinfo/python-list
Re: __dict__ is neato torpedo!
On 2011.06.11 10:08 PM, Ian Kelly wrote: For immutable objects such as ints, this doesn't matter. For mutable objects such as lists, it can: Well, that's confusing. How would I make actual copies? -- http://mail.python.org/mailman/listinfo/python-list
Re: __dict__ is neato torpedo!
Andrew Berg bahamutzero8...@gmail.com writes: On 2011.06.11 10:08 PM, Ian Kelly wrote: For immutable objects such as ints, this doesn't matter. For mutable objects such as lists, it can: Well, that's confusing. It's exactly the same as with an ordinary assignment (‘a = b’) in Python. You will likely want to work through the Python Tutorial URL:http://docs.python.org/tutorial/ and experiment with the samples as you go, in order to ground the Python data model in your mind. How would I make actual copies? At what level? You can create a new dict or a new list by feeding the esiting one to the constructor for the type. Or you can use the various methods in the ‘copy’ module depending on what you want. Be aware, though, that most Python code gets by just fine without explicitly making copies, and I hardly ever see the ‘copy’ module actually used. Work through the tutorial, understand the data model, and work with it to get better results. -- \ “Give a man a fish, and you'll feed him for a day; give him a | `\religion, and he'll starve to death while praying for a fish.” | _o__) —Anonymous | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
which threading libraries to use?
Hi, Are there any reasons besides personal preference to use one particular threading library over the other? Eventlet, Twisted, and Python's native Threading class, or are there even others? Are there any licensing or redistribution restrictions that I should be worried about? Which ones do you consider best documented? Most thread-safe? Efficient? Ultimately this will be used for asynchronous SNMP, HTTP, and WMI. I don't think this will need to evolve into a multi-process project, unless of course that is much easier to do than multi-threading? Thanks, Dennis O. -- http://mail.python.org/mailman/listinfo/python-list
Re: __dict__ is neato torpedo!
On 2011.06.11 10:40 PM, Ben Finney wrote:
It's exactly the same as with an ordinary assignment (‘a = b’) in
Python.
Fair enough.
How would I make actual copies?
At what level?
Level? I just want to be able to create an object b with values from
dictionary a, and not have changes to a reflect b and vice-versa once b
is created.
You can create a new dict or a new list by feeding the
esiting one to the constructor for the type.
Not sure what you mean here. I thought you meant it copies a dictionary
when used as input in an __init__() method, but I tried that in the
interpreter and a still affects b:
class testObj():
... def __init__(self,input):
... self.__dict__.update(input)
...
a = dict(list=['one', 'two'], str='hello')
b = testObj(a)
a['list'].append('three')
a
{'list': ['one', 'two', 'three'], 'str': 'hello'}
b.list
['one', 'two', 'three']
Or you can use the various
methods in the ‘copy’ module depending on what you want.
copy.deepcopy() looks appealing, but I don't know what the docs mean by
administrative data structures.
Be aware, though, that most Python code gets by just fine without
explicitly making copies, and I hardly ever see the ‘copy’ module
actually used.
Now that I think about it, I could probably restrict myself to immutable
types inside the dictionary without much problem. Was that your point,
or did you mean something else?
--
http://mail.python.org/mailman/listinfo/python-list
Re: which threading libraries to use?
On Sun, Jun 12, 2011 at 2:10 PM, Dennis daoden...@gmail.com wrote: Hi, Are there any reasons besides personal preference to use one particular threading library over the other? Eventlet, Twisted, and Python's native Threading class, or are there even others? Are there any licensing or redistribution restrictions that I should be worried about? Which ones do you consider best documented? Most thread-safe? Efficient? I use the native Threading class, myself, largely because it's so easy to switch to multiprocessing if the GIL starts to get in the way. YMMV if you don't use CPython. Ultimately this will be used for asynchronous SNMP, HTTP, and WMI. I don't think this will need to evolve into a multi-process project, unless of course that is much easier to do than multi-threading? In all probability, your threads will spend 99% of their time waiting for the network. This makes threads very effective, and largely eliminates the GIL issues (if they occasionally have to take turns, it's not going to affect things much). Pick whichever threading library suits your coding style; they'll all work, most likely. Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: __dict__ is neato torpedo!
On Sat, Jun 11, 2011 at 10:32 PM, Andrew Berg bahamutzero8...@gmail.com wrote:
On 2011.06.11 10:40 PM, Ben Finney wrote:
It's exactly the same as with an ordinary assignment (‘a = b’) in
Python.
Fair enough.
How would I make actual copies?
At what level?
Level? I just want to be able to create an object b with values from
dictionary a, and not have changes to a reflect b and vice-versa once b
is created.
It sounds like the copy.deepcopy function is what you want:
from copy import deepcopy
class X(object): pass
...
a = X()
a.fruit = ['apples']
b = deepcopy(a)
a.fruit
['apples']
b.fruit
['apples']
a.fruit.append('oranges')
a.fruit
['apples', 'oranges']
b.fruit
['apples']
Or you can use the various
methods in the ‘copy’ module depending on what you want.
copy.deepcopy() looks appealing, but I don't know what the docs mean by
administrative data structures.
It just means that you don't always want absolutely everything copied.
For example:
class World(object): pass
...
class Actor(object):
... def __init__(self, world):
... self.world = world
...
class Action(object):
... def __init__(self, actor):
... self.actor = actor
...
a = Action(Actor(World()))
b = deepcopy(a)
a.actor is b.actor
False
a.actor.world is b.actor.world
False
The intention here is probably that a and b should both be part of the
same World, but as you can see that is not the case; the World got
copied along with everything else. Python provides machinery to let
you avoid deep copying absolutely everything, but it's important to be
aware of cases like this.
Cheers,
Ian
--
http://mail.python.org/mailman/listinfo/python-list
[issue11610] Improved support for abstract base classes with descriptors
Daniel Urban urban.dani...@gmail.com added the comment: It doesn't work with staticmethod: import abc class C(metaclass=abc.ABCMeta): ... @staticmethod ... @abc.abstractmethod ... def foo(x): ... raise NotImplementedError() ... class D(C): ... @staticmethod ... def foo(x): ... return x + 1 ... D() Traceback (most recent call last): File stdin, line 1, in module TypeError: Can't instantiate abstract class D with abstract methods foo.__func__ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improved support for abstract base classes with descriptors
Darren Dale dsdal...@gmail.com added the comment: On Sat, Jun 11, 2011 at 3:11 AM, Daniel Urban rep...@bugs.python.org wrote: Daniel Urban urban.dani...@gmail.com added the comment: It doesn't work with staticmethod: import abc class C(metaclass=abc.ABCMeta): ... @staticmethod ... @abc.abstractmethod ... def foo(x): ... raise NotImplementedError() ... class D(C): ... @staticmethod ... def foo(x): ... return x + 1 ... D() Traceback (most recent call last): File stdin, line 1, in module TypeError: Can't instantiate abstract class D with abstract methods foo.__func__ You still need to use @abc.abstractstaticmethod. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12310] Segfault in test_multiprocessing
Charles-François Natali neolo...@free.fr added the comment: I think it might be related to Issue #6721. Using a mutex/condition variable after fork (from the child process) is unsafe: it can lead to deadlocks, and on OS-X, it seems like it can lead to segfaults. Normally, Queue's synchronization primitives are reinitialized after fork, see Queue._after_fork() method. But here, what happens is the following (well, that's an hypothesis): Lib/multiprocessing/process.py, line 270 in _bootstrap : _current_process = self util._finalizer_registry.clear() util._run_after_forkers() - the old _current_process' reference count drops to zero - it's deallocated, and since it holds the last reference to a Queue, the queue is finalized - as a consequence, the Queue._finalize_close() callback (registered through a Finalize object) is called - Queue._finalize_close() tries to acquire, signal and release the _notempty Condition, but the Condition hasn't been reinitialized yet, because util._run_after_forkers() is called 2 lines below - segfault It's probably been triggered by Antoine's patches, but I'm pretty sure this bug has always been there. I think that moving util._run_after_forkers() up 2 lines should fix the segfaults, but with that change test_number_of_objects fails (I didn't investigate why). -- nosy: +neologix ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12310 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11553] Docs for: import, packages, site.py, .pth files
Graham Wideman initcont...@grahamwideman.com added the comment: Hi Eric, Thanks for starting to review this, and your responses are encouraging. Some comments inline below. FWIW, along the way I accumulated my own notes on this topic, on some pages here: grahamwideman.wikispaces.com (Left navigation panel...) Software development Python Organization for common modules Might be of interest as feedback on the digging process I needed in order to get some clarity on these issues, and also shows my references. Exactly what variants of arguments are possible, and what are their effects? Does http://docs.python.org/dev/library/functions#__import__ help? Does http://docs.python.org/dev/library/importlib ? Well somewhat overkill -- because the matter of interest was args for from... and import, while the docs you mention are for more complicated underlying functions. (Interesting nonetheless.) Current docs are unclear on points such as: -- is __init__.py needed on subpackage directories? Yes, it always has. I think there was some discussion about removing them in py3k, but this was rejected. I came to same conclusion.. but have seen it described otherwise (in at least one book), so good to state this explicitly. -- the __all__ variable: Does it act generally to limit visibility of a module or package's attributes, or does pertain only to the 'from...import *' statement? Both. I'm pretty sure that's not correct -- pretty sure that __all__ only specifies what's included in from...import *, and does not prevent access via from...import specific_attrib. But I may have tested incorrectly. Seriously misleading discussion of .pth files. [snip] Agreed. Cool -- I think it's well worth fixing this area for sure! In addsitepackages(), the library directory for Windows (the else clause) is shown as lower-case 'lib' instead of 'Lib'. I don’t see any else clause in the 2.7 or 3.3 code. Otherwise you’re right. Sorry, the lowecase 'lib' issue is in getsitepackages()... if sys.platform in(...) ... else:... sitepackages.append(os.path.join(prefix, lib, site-packages)) sys Could helpfully point to a discussion of the typical items to be found in sys.path under normal circumstances Hm, this would be very platform-specific. What use cases would that help? It would demystify how python already knows how to find various things under vanilla circumstances. 'Installing Python Modules' document Windows has no concept of a user’s home directory, and so on. The author probably meant that there was no $HOME environment variable, ~ shortcut and all that. Fair enough, but in actuality there *is* a user-specific location (on Windows) examined by site.py, which is in %APPDATA%\Python\. For Windows suggests 'prefix' (default: C:\Python) as an installation directory. This is indeed one of the possible 'site-package' directories, but surely it is deprecated in favor of C:\Python\Lib\site-packages, which this section does not mention. Don’t confuse the prefix and the install dir. The directory for Python modules is computed as prefix + Lib/site-packages. Currently, under Alternate installation: Windows (the prefix scheme), it says: python setup.py install --prefix=\Temp\Python to install modules to the \Temp\Python directory on the current drive. Does this really mean install modules to \Temp\Python\Lib\site-packages? (And as a side point, surely installing under the Temp directory is a strange location to pick for an example?) That was my initial feeback; I think I’ve covered all of your points. Looking forward! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11553 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improved support for abstract base classes with descriptors
Darren Dale dsdal...@gmail.com added the comment: [...] Traceback (most recent call last): File stdin, line 1, in module TypeError: Can't instantiate abstract class D with abstract methods foo.__func__ You still need to use @abc.abstractstaticmethod. Thinking about this some more, I think the error you found should be considered a problem. The issue is with the descriptor access itself: In class C we inspect the staticmethod instance in the namespace dict passed to ABCMeta and find foo's abstract __func__. But later, ABCMeta identifies C as a base of D, identifies C.foo.__func__ from C.__abstractmethods__, then does a getattr on the formative D class. D.__dict__['foo'] is a descriptor, which when accessed as D.foo returns D.__dict__['foo'].__func__ (as opposed to the other descriptors we have been discussing, where descriptor get access is only invoked by an instance of the class). ABCMeta needs to inspect the descriptor itself, not whatever the descriptor wants to return when accessed. We can't use D.__dict__ to access the foo descriptor, since some other base class of D may have provided the concrete implementation of foo. Does anyone know another way to search the MRO and return the foo descriptor? You helped bring up another point: all functions are descriptors, since they all have __get__ methods. That means every method is going to be inspected for abstract members. Is this a problem? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11553] Docs for: import, packages, site.py, .pth files
Nick Coghlan ncogh...@gmail.com added the comment: Thanks for getting started with such a detailed review on this Graham. We've known the documentation in this area has been flawed for a long time, but actually *fixing* seemed like such a big task that it has tended to get pushed to the bottom of our respective to-do lists. And so as things have been tweaked, the already flawed documentation has fallen even further out of date (as it wasn't always clear where updates should be included). Simply breaking it down into a smaller list of easier to tackle problems is a big step towards getting something done about it. A couple of specific notes: __all__ only affects import *, and may also affect documentation tools (e.g. pydoc will respect __all__ when deciding what to display). It has no effect on attribute retrieval from modules. pkgutil.extend_path() is used to modify pkg.__path__ attributes, *not* sys.path. It is used to allow a single package to span multiple directories, forming the basis for namespace packages (see http://www.python.org/dev/peps/pep-0382/#namespace-packages-today). Packages are technically a kind of module, but we're somewhat inconsistent in our use of the term module. Sometimes it means all kinds of modules (frozen, builtin, extension, package, compiled, source), sometimes it means anything-but-a-package and occasionally it specifically means pure Python modules. In theory, context should make it clear which interpretation is intended. In practice, the boundaries between the first two meanings get a little blurry. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11553 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improved support for abstract base classes with descriptors
Nick Coghlan ncogh...@gmail.com added the comment: inspect.getattr_static has the necessary logic to search for descriptors without invoking them. However, it may be better to revert to the idea of pushing this functionality back onto the individual descriptors and have the problematic descriptors like property and staticmethod simply implement __isabstractmethod__ as a property. property: @property def __isabstractmethod__(self): return (self.fget.__isabstractmethod__ or self.fset.__isabstractmethod__ or self.fdel.__isabstractmethod__) staticmethod/classmethod: @property def __isabstractmethod__(self): return self.__func__.__isabstractmethod__ With this approach, the one true way to handle abstract descriptors would be to do: #instance method @abstractmethod def f(self): ... @property @abstractmethod def f(self): ... @classmethod @abstractmethod def f(self): ... @staticmethod @abstractmethod def f(self): ... This wouldn't allow for the prettier error messages, but it's much cleaner than having ABCMeta trawling through class attribute dir() lists. -- nosy: +michael.foord ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improved support for abstract base classes with descriptors
Darren Dale dsdal...@gmail.com added the comment: On Sat, Jun 11, 2011 at 8:55 AM, Nick Coghlan rep...@bugs.python.org wrote: Nick Coghlan ncogh...@gmail.com added the comment: inspect.getattr_static has the necessary logic to search for descriptors without invoking them. Unfortunately, we can't import inspect, even inside ABCMeta.__new__. However, it may be better to revert to the idea of pushing this functionality back onto the individual descriptors and have the problematic descriptors like property and staticmethod simply implement __isabstractmethod__ as a property. property: @property def __isabstractmethod__(self): return (self.fget.__isabstractmethod__ or self.fset.__isabstractmethod__ or self.fdel.__isabstractmethod__) staticmethod/classmethod: @property def __isabstractmethod__(self): return self.__func__.__isabstractmethod__ That's a good idea. With this approach, the one true way to handle abstract descriptors would be to do: #instance method @abstractmethod def f(self): ... @property @abstractmethod def f(self): ... @classmethod @abstractmethod def f(self): ... @staticmethod @abstractmethod def f(self): ... This wouldn't allow for the prettier error messages, but it's much cleaner than having ABCMeta trawling through class attribute dir() lists. Those classes could conceivably do: @property def __abstractmethods__(self): return (..., ...) It would not be required, but if ABCMeta found it, it could use it. Just a thought. Darren -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11553] Docs for: import, packages, site.py, .pth files
Changes by Greg Słodkowicz jerg...@gmail.com: -- nosy: +Greg.Slodkowicz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11553 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12291] file written using marshal in 3.2 can be read by 2.7, but not 3.2 or 3.3
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: Patch is now in my public sandbox on hg.python.org. -- hgrepos: +26 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12291 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11553] Docs for: import, packages, site.py, .pth files
Graham Wideman initcont...@grahamwideman.com added the comment: Hi Nick: Thanks for your additional points. Comments inline: __all__ only affects import *, and may also affect documentation tools (e.g. pydoc will respect __all__ when deciding what to display). It has no effect on attribute retrieval from modules. That's indeed my understanding. So the doc (6. Simple statements) which says that __all__ determines the list of public names is a bit of a red herring. Attributes are accessible (ie: public) regardless of whether on the __all__ list. Instead the __all__ list establishes the list of names imported by *, and makes those names reference-able without a module prefix. (Plus gives hints about intent to doc tools.) pkgutil.extend_path() is used to modify pkg.__path__ attributes, *not* sys.path. Understood, and perhaps my point was obtuse. I was pointing out that the doc for extend_path discusses .pkg entries which point to package dirs, and that this, it says, is like .pth files. I claim that an entry in a .pth files should NOT point to a package dir, but rather to one level up: to a dir that *contains* package dirs. (Pointing a .pth entry directly at a package dir will break package behavior by exposing the constituent modules to sys.path.) Hence the doc for extend_path is misleadingly suggesting a wrong idea about .pth files. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11553 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12291] file written using marshal in 3.2 can be read by 2.7, but not 3.2 or 3.3
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: For some reason, Create Patch is failing with a [Errno 2] No such file or directory: '/home/roundup/trackers/tracker/cpython/Doc/Makefile' I've logged an issue on the meta tracker: http://psf.upfronthosting.co.za/roundup/meta/issue405 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12291 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12310] Segfault in test_multiprocessing
Antoine Pitrou pit...@free.fr added the comment: Less disruptive approach: old_process = _current_process _current_process = self try: util._finalizer_registry.clear() util._run_after_forkers() finally: del old_process This will delay finalization of the old process object until after _run_after_forkers() is executed, without (hopefully) messing with semantics. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12310 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10115] Support accept4() for atomic setting of flags at socket creation
Charles-François Natali neolo...@free.fr added the comment: No one seems to object, and since this approach has been suggested by Martin and is consistent with the posix module's policy (i.e. a thin wrapper around the underlying syscall), I guess you can go ahead. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10115 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12287] ossaudiodev: stack corruption with FD = FD_SETSIZE
Charles-François Natali neolo...@free.fr added the comment: For oss_check_closed.diff, should I apply it to default only or to every branch? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12287 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12287] ossaudiodev: stack corruption with FD = FD_SETSIZE
Antoine Pitrou pit...@free.fr added the comment: For oss_check_closed.diff, should I apply it to default only or to every branch? Only default I'd say. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12287 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10897] UNIX mmap unnecessarily dup() file descriptor
Charles-François Natali neolo...@free.fr added the comment: Perhaps by adding some new argument to the mmap constructor? (dup_fd = True) I don't really like the idea of exposing the FD duplication to the user, because: - it's an implementation detail - it doesn't reflect any argument of the POSIX mmap version - it should False by default I really think that application code expecting to be able to resize the mmap after closing the FD is broken, but I'm also a really strong advocate of backward compatibility... I don't see any satisfying solution. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10897 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12315] Improve http.client.HTTPResponse.read documentation
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +orsenthil stage: - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12315 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12310] Segfault in test_multiprocessing
Charles-François Natali neolo...@free.fr added the comment: Yes, I also tried this. This fixed the test_multiprocessing failure, but I think it triggered a failure in test_concurrent_futures (didin't look in more detail). Would it be possible to try this on the buildbot to see if it fixes the segfaults? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12310 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improved support for abstract base classes with descriptors
Darren Dale dsdal...@gmail.com added the comment: [...] This wouldn't allow for the prettier error messages, but it's much cleaner than having ABCMeta trawling through class attribute dir() lists. I think there is another reason to do it this way. Suppose I have a custom descriptor MyProperty that stores its getter as MyProperty.my_fget. In this example: class C: @property @abstractmethod def foo(self): return 1 class D: @MyProperty def foo(self): return 2 if ABCMeta determines C.foo.fget is abstract, it will not recognize that D.foo.my_fget supplies the concrete implementation. MyProperty may provide the same interface as property, it may even subclass property, but there is no guarantee its implementation conforms to property the way ABCMeta is expecting it to. The downside to making __isabstractmethod__ a property is that if C declares foo to be a read/write property, and D redefines foo as read-only and concrete, ABCMeta will not recognize the oversight. That seems a significant deficiency to me. I'm not sure how to proceed. Darren -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12287] ossaudiodev: stack corruption with FD = FD_SETSIZE
Roundup Robot devnull@devnull added the comment: New changeset d0952a2fb7bd by Charles-François Natali in branch 'default': Issue #12287: In ossaudiodev, check that the device isn't closed in several http://hg.python.org/cpython/rev/d0952a2fb7bd -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12287 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9098] MSYS build fails with `S_IXGRP' undeclared
Yuri y...@tsoft.com added the comment: I fixed all build problems on the current MinGW32. python.exe builds ok, but build fails since python.exe can't find some modules after this. Not sure why. -- keywords: +patch nosy: +yurivict Added file: http://bugs.python.org/file22329/python-3.2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9098 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11595] Miscellaneous bugs in cfg_to_args() utility function
Roundup Robot devnull@devnull added the comment: New changeset 303e3693d634 by Éric Araujo in branch 'default': Move useful function to packaging.util. http://hg.python.org/cpython/rev/303e3693d634 New changeset 06670bd0e59e by Éric Araujo in branch 'default': Fix assorted bugs in packaging.util.cfg_to_args (#11595). http://hg.python.org/cpython/rev/06670bd0e59e -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11595 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11599] Useless error message when distutils fails compiling
Roundup Robot devnull@devnull added the comment: New changeset 3ba34c03f2fc by Éric Araujo in branch 'default': Adjust logging in packaging.util.spawn (related to #11599) http://hg.python.org/cpython/rev/3ba34c03f2fc -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11599 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12240] Allow multiple setup_hooks
Roundup Robot devnull@devnull added the comment: New changeset 5f0cd4844061 by Éric Araujo in branch 'default': Allow multiple setup hooks in packaging’s setup.cfg files (#12240). http://hg.python.org/cpython/rev/5f0cd4844061 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12240 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12313] make install misses packaging module
Éric Araujo mer...@netwok.org added the comment: Also you may want to add some of the packaging test directories to those excluded in the calls to compileall.py a little further down in the libinstall target. Ah, good one. I guess doing this could have prevented http://hg.python.org/cpython/rev/9041520be581 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12313 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue828450] sdist generates bad MANIFEST on Windows
Éric Araujo mer...@netwok.org added the comment: I just recreated this patch against version 2.7, so I'm not sure it can be applied to all the listed versions. It’s okay, distutils in 2.7 and 3.x is very similar, I can port. Note: there still are two pathes, one for sdist.py and another for test_sdist.py Why? hg diff can create one patch for many files. It’s a bit easier if you upload just one patch. Anyway, it’s not an issue, just upload the missing patch for sdist.py. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue828450 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11595] Miscellaneous bugs in cfg_to_args() utility function
Éric Araujo mer...@netwok.org added the comment: Thanks again! -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11595 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11599] Useless error message when distutils fails compiling
Éric Araujo mer...@netwok.org added the comment: I intend to ask on distutils-sig whether doing the change in distutils would break code. -- assignee: tarek - eric.araujo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11599 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12279] Add build_distinfo command to packaging
Éric Araujo mer...@netwok.org added the comment: I forgot one thing: setuptools’ egg_info command does write a list of paths, so we can look at how it solved the problem with the RECORD and RESOURCES files. Higery: Michael is willing to work with you on this bug. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12279 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12240] Allow multiple setup_hooks
Éric Araujo mer...@netwok.org added the comment: Done. -- assignee: tarek - eric.araujo resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12240 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7511] msvc9compiler.py: ValueError when trying to compile with VC Express
Éric Araujo mer...@netwok.org added the comment: Hmm, in http://bugs.python.org/issue7511#msg106420 Tarek appeared to be supportive of the patch. I believe Martin has more knowledge about Windows. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7511 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12317] inspect.getabsfile() is not documented
Changes by Giampaolo Rodola' g.rod...@gmail.com: -- assignee: giampaolo.rodola nosy: giampaolo.rodola priority: normal severity: normal status: open title: inspect.getabsfile() is not documented versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12317 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12169] Factor out common code for d2 commands register, upload and upload_docs
John Edmonds pocketcooki...@gmail.com added the comment: Here is the patch, re-written for the packaging module. -- Added file: http://bugs.python.org/file22330/patch.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12169 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9284] inspect.findsource() cannot find source for doctest code
Roundup Robot devnull@devnull added the comment: New changeset 527c40add91d by Benjamin Peterson in branch '2.7': allow fake filenames in findsource (closes #9284) http://hg.python.org/cpython/rev/527c40add91d New changeset 6cc4579dca02 by Benjamin Peterson in branch '3.2': allow fake filenames in findsource (closes #9284) http://hg.python.org/cpython/rev/6cc4579dca02 New changeset f05affb0bb2a by Benjamin Peterson in branch 'default': merge 3.2 (#9284) http://hg.python.org/cpython/rev/f05affb0bb2a -- nosy: +python-dev resolution: - fixed stage: test needed - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9284 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12206] Documentation Std. Library 15.7.5 LogRecord objects: Parameters: level(currently wrong) - levelno (correct)
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: Attached is a simple patch clarifying that the level argument in the constructor maps to the two LogRecord attributes, levelno and levelname, -- keywords: +patch Added file: http://bugs.python.org/file22331/patch12206.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12206 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12318] list + tuple inconsistency
New submission from Filip Gruszczyński grusz...@gmail.com: You can do this: [1] + (1,) Traceback (most recent call last): File stdin, line 1, in module TypeError: can only concatenate list (not tuple) to list But you can do this: result = [1] result += (1,) result [1, 1] Is it the expected behaviour, that += does implicit coercion? -- messages: 138185 nosy: gruszczy priority: normal severity: normal status: open title: list + tuple inconsistency versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12318 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12318] list + tuple inconsistency
Filip Gruszczyński grusz...@gmail.com added the comment: Obviously first sentence should be You can't do this:. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12318 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12206] Documentation Std. Library 15.7.5 LogRecord objects: Parameters: level(currently wrong) - levelno (correct)
Roundup Robot devnull@devnull added the comment: New changeset bb6fe43191c0 by Vinay Sajip in branch '3.2': Issue #12206: documentation for LogRecord constructor updated re. the level argument. http://hg.python.org/cpython/rev/bb6fe43191c0 New changeset 596adf14914c by Vinay Sajip in branch 'default': Merged documentation update for issue #12206. http://hg.python.org/cpython/rev/596adf14914c -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12206 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12206] Documentation Std. Library 15.7.5 LogRecord objects: Parameters: level(currently wrong) - levelno (correct)
Changes by Vinay Sajip vinay_sa...@yahoo.co.uk: -- assignee: docs@python - vinay.sajip ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12206 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12318] list + tuple inconsistency
Raymond Hettinger raymond.hettin...@gmail.com added the comment: Yes, this is the expected behavior and yes, it is inconsistent. It's been that way for a long while and Guido said he wouldn't do it again (it's in his list of regrets). However, we're not going to break code by changing it (list.__iadd__ working like list.extend). -- nosy: +rhettinger resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12318 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improved support for abstract base classes with descriptors
Eric Snow ericsnowcurren...@gmail.com added the comment: Perhaps rather than changing ABCMeta, provide a base descriptor class that has __isabstractmethod__ implemented to calculate the abstractness. Then property could use that, as could any of the other relevant descriptors we have around. The __isabstractmethod__ attribute of the descriptor would itself need to be a data-descriptor (which property() is). That would ensure that __isabstractmethod__ is not set directly on the descriptor instance. I agree with Nick that it may be better to have the descriptor classes take care of managing __isabstractmethod__ themselves, instead of having ABCMeta compute it. Special-casing ABCMeta to handle custom __isabstractmethod__ calculation for any specific type seems like something we should avoid. Per your last message, if a specific descriptor has an abstract setter then the descriptor should be considered abstract. If the implementation of that attribute is not a descriptor should it raise a TypeError? If it is a descriptor but it does not have a setter, should it likewise fail? I'm not so sure. We already don't enforce types on abstract attributes. You don't have to implement an abstractproperty with a property, an abstractstaticmethod with a staticmethod, nor an abstractclassmethod with a classmethod. For that matter you don't have to implement an abstractmethod with a function. It just has to be an object bound to the same name. Should descriptors get special treatment over any other type that implements __isabstractmethod__? That brings up a concern of mine. I've found the name abstractmethod (specifically the method part) to be misleading. Any attribute can be abstract and ABCMeta only cares about __isabstractmethod__. Maybe having method in the name is meant to imply the expected use case? I would rather they were called __isabstractattribute__, and __abstractattributes__, which would be less confusing when using ABCs, particularly at first. Having attribute in the name is nice, since it makes it clear we're talking about attributes, rather than other abstraction contexts. Having a specific abstractmethod decorator is still good since we only decorate functions in an ABC. I'm +1 for deprecating abstractproperty and really all the decorators except abstractmethod (if the use cases were addressed). If abstractmethod were smart about on which object it sets __isabstractmethod__, the other decorators would be unnecessary; and the order in which you decorate would not matter as much. The other decorators could become simple wrappers around abstractmethod if we felt the need to keep them around. It's nice that the decorators say with what you are expecting to replace them, but you can get that by using the corresponding normal decorators. -- nosy: +ericsnow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12310] Segfault in test_multiprocessing
STINNER Victor victor.stin...@haypocalc.com added the comment: Would it be possible to try this on the buildbot to see if it fixes the segfaults? You can fork cpython, modify the code, and run a custom buildbot on your clone. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12310 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11553] Docs for: import, packages, site.py, .pth files
Nick Coghlan ncogh...@gmail.com added the comment: Public name is a term that describes a convention, not anything enforced by the interpreter. Names starting with underscores typically aren't public either (unless documented otherwise), but that has no effect on the ability to retrieve them as attributes. A glossary entry defining the term may be worthwhile (perhaps with a reference to pydoc.visiblename()) Dirs mentioned in .pkg files *should* be added to the path. It's just that the path in question is pkg.__path__, not sys.path. That could probably be made clearer, but the docs aren't wrong as they stand. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11553 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improved support for abstract base classes with descriptors
Nick Coghlan ncogh...@gmail.com added the comment: Remember the goal here is *not* to completely eliminate the need to test that objects implement an ABC correctly. It's to make it easier to declare the expected interface in a way that helps readers of the ABC definition to figure out what is going on, and to reduce the proliferation of abstract descriptors. Since we made a deliberate choice not to do signature checks when ABCs were added to the language, there's nothing an ABC can do to stop someone (for example) overriding an abstract method or descriptor foo with foo = 1. That's almost certainly wrong, but it's wrong at a level that ABCs don't care about. If someone incorrectly overrides a read/write property with a read-only property and there's nothing in their test suite that picks that up, then that's a flaw in the test suite, not a flaw in the ABC itself. Regarding the naming, @abstractmethod and __isabstractmethod__ are definitely about methods, or method-based descriptors (such as property). There *could* be a case to be made to allow for abstract data attributes, but really, using an abstract property should cover that use case well enough. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12239] msilib VT_EMPTY SummaryInformation properties raise an error (suggest returning None)
Changes by Mark Mc Mahon mtnbikingm...@gmail.com: -- keywords: +patch Added file: http://bugs.python.org/file22332/support_vt_empty_in_summary_getproperty.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12239 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11553] Docs for: import, packages, site.py, .pth files
Graham Wideman initcont...@grahamwideman.com added the comment: Public name is a term that describes a convention, not anything enforced by the interpreter. And I guess that's really the main point. In other languages Public means accessible, and Private means not so. In Python, Public means suggested for outside consumption, and Private means not so intended, but nonetheless accessible. If that was reiterated near the discussion of __all__ it would be most helpful. Dirs mentioned in .pkg files *should* be added to the [...] pkg.__path__, not sys.path. That could probably be made clearer, but the docs aren't wrong as they stand. Again I've not managed to draw attention to the exact point of contention. 1. A dir added to a .pkg file evidently should be an actual package dir. 2. A dir added to a .pth file should NOT be an actual package dir. It should be the dir at the level above. Thus the entries in .pkg and .pth files point to different kinds of things, yet the doc I pointed to asserts they are the same in this regard. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11553 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue828450] sdist generates bad MANIFEST on Windows
higery shoulderhig...@gmail.com added the comment: OK. I recreated a full version patch. I'll remove old patches. -- Added file: http://bugs.python.org/file22333/change_path_separator_fullversion.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue828450 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue828450] sdist generates bad MANIFEST on Windows
Changes by higery shoulderhig...@gmail.com: Removed file: http://bugs.python.org/file21713/change_path_separator_in_MANIFEST.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue828450 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue828450] sdist generates bad MANIFEST on Windows
Changes by higery shoulderhig...@gmail.com: Removed file: http://bugs.python.org/file22328/test_manifest_reading_sdist.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue828450 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improved support for abstract base classes with descriptors
Eric Snow ericsnowcurren...@gmail.com added the comment: Didn't mean to sidetrack. :) I really appreciate the effort Darren has put into this. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12279] Add build_distinfo command to packaging
higery shoulderhig...@gmail.com added the comment: Higery: Michael is willing to work with you on this bug. OK. :) -- Added file: http://bugs.python.org/file22334/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12279 ___brdiv class=gmail_quoteblockquote class=gmail_quote style=margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex; Higery: Michael is willing to work with you on this bug.br/blockquotedivbrOK. :)br/div/div ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12279] Add build_distinfo command to packaging
Changes by higery shoulderhig...@gmail.com: Removed file: http://bugs.python.org/file22334/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12279 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9035] os.path.ismount on windows doesn't support windows mount points
Mark Mc Mahon mtnbikingm...@gmail.com added the comment: I was looking at this - and see that (at least as far as GetFileAttributes is concerned) that a mount and a linked directory are seen the same... Here are some tests using ctypes # mounted drive hex(windll.kernel32.GetFileAttributesW(urc:\temp\test_c_mount)) '0x410' # normal directory hex(windll.kernel32.GetFileAttributesW(urc:\temp\orig)) '0x10' # link (created via mklink /d c:\temp\orig c:\temp\here2 hex(windll.kernel32.GetFileAttributesW(urc:\temp\here2)) '0x410' On futher searching - I found the following link: http://msdn.microsoft.com/en-us/library/aa363940%28v=vs.85%29.aspx So the function ismount will need to do the following a) Get the file attributes b) check that it's a directory and is a reparse point c) Use FindFirstFile (and FindNextFile? - I need to test more) to fill in WIN32_FIND_DATA.dwResearved0 d) Check that against IO_REPARSE_TAG_MOUNT_POINT (0xA003) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9035 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9035] os.path.ismount on windows doesn't support windows mount points
Changes by Brian Curtin br...@python.org: -- nosy: +brian.curtin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9035 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
