Re: [Python-Dev] elimination of scope bleeding ofiteration variables
Delaney, Timothy (Tim) wrote: So would this also be a SyntaxError? for x in stuff: x = somethingelse That would be something to be debated. I don't really mind much one way or the other. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r45850 - in python/trunk: Doc/lib/libfuncs.tex Lib/test/test_subprocess.py Misc/NEWS Objects/fileobject.c Python/bltinmodule.c
On 5/1/06, Tim Peters [EMAIL PROTECTED] wrote: Author: neal.norwitz Date: Tue May 2 06:43:14 2006 New Revision: 45850 Modified: python/trunk/Doc/lib/libfuncs.tex python/trunk/Lib/test/test_subprocess.py python/trunk/Misc/NEWS python/trunk/Objects/fileobject.c python/trunk/Python/bltinmodule.c Log: SF #1479181: split open() and file() from being aliases for each other. Umm ... why? I suppose I wouldn't care, except it left I'll let Aahz answer that, it's his patch. test_subprocess failing on all the Windows buildbots, and I don't feel like figuring out why. To a first approximation, test_universal_newlines_communicate() now takes the # Interpreter without universal newline support branch on Windows, but shouldn't. I tried to fix that breakage. n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r45850 - in python/trunk: Doc/lib/libfuncs.tex Lib/test/test_subprocess.py Misc/NEWS Objects/fileobject.c Python/bltinmodule.c
[Tim] ... test_subprocess failing on all the Windows buildbots [Neal] I tried to fix that breakage. You succeeded! Thanks. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r45850 - in python/trunk:Doc/lib/libfuncs.tex Lib/test/test_subprocess.py Misc/NEWSObjects/fileobject.c Python/bltinmodule.c
SF #1479181: split open() and file() from being aliases for each other. Umm ... why? [/F] so that introspection tools can support GvR's pronouncement that open should be used to open files, and file should be used as a type representing standard (current stdio-based) file handles. Maybe some of the intended changes are missing? The post-patch docstrings don't draw this distinction, and I'm lost about what else introspection tools could be looking at to make the distinction (special-casing the names? but they could have done that before): print open.__doc__ open(name[, mode[, buffering]]) - file object Open a file using the file() type, returns a file object. print file.__doc__ file(name[, mode[, buffering]]) - file object Open a file. The mode can be 'r', 'w' or 'a' for reading (default), writing or appending. The file will be created if it doesn't exist when opened for writing or appending; it will be truncated when opened for writing. Add a 'b' to the mode for binary files. Add a '+' to the mode to allow simultaneous reading and writing. If the buffering argument is given, 0 means unbuffered, 1 means line buffered, and larger numbers specify the buffer size. Add a 'U' to mode to open the file for input with universal newline support. Any line ending in the input file will be seen as a '\n' in Python. Also, a file so opened gains the attribute 'newlines'; the value for this attribute is one of None (no newline read yet), '\r', '\n', '\r\n' or a tuple containing all the newline types seen. 'U' cannot be combined with 'w' or '+' mode. In Python 2.4, the docstrings were of course the same (the current trunk's file.__doc__ except for a line at the end). Since all useful info about how to open a file has been purged from open()'s docstring, if you've got the intent right, looks like the implementation got it backwards ;-) OK, maybe this is what you have in mind: type(open) type 'builtin_function_or_method' type(file) type 'type' Fine, if that's all there really is to this, but I think it's a net loss if open()'s docstring regression stands -- someone should finish this job, or it should be reverted. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] elimination of scope bleeding ofiteration variables
Greg Ewing [EMAIL PROTECTED] wrote: Delaney, Timothy (Tim) wrote: So would this also be a SyntaxError? for x in stuff: x = somethingelse That would be something to be debated. I don't really mind much one way or the other. for line in lines: line = line.rstrip() ... I'm generally -0 on the raise a SyntaxError in this particular case, and am +0 on the double use below: for x in y: for x in z: - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Reminder: call for proposals Python Language and Libraries Track for Europython 2006
Python Language and Libraries A track about Python the Language, all batteries included. Talks about the language, language evolution, patterns and idioms, implementations (CPython, IronPython, Jython, PyPy ...) and implementation issues belong to the track. So do talks about the standard library or interesting 3rd-party libraries (and frameworks), unless the gravitational pull of other tracks is stronger. Of course talks to detail new features in the upcoming 2.5 release are more than welcome. Deadline is 31th of May. The full call and submission links are at: http://www.europython.org/sections/tracks_and_talks/call-for-proposals Thanks, Samuele Pedroni ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r45850 - inpython/trunk:Doc/lib/libfuncs.tex Lib/test/test_subprocess.pyMisc/NEWSObjects/fileobject.c Python/bltinmodule.c
Tim Peters wrote: SF #1479181: split open() and file() from being aliases for each other. Umm ... why? [/F] so that introspection tools can support GvR's pronouncement that open should be used to open files, and file should be used as a type representing standard (current stdio-based) file handles. Maybe some of the intended changes are missing? The post-patch docstrings don't draw this distinction, and I'm lost about what else introspection tools could be looking at to make the distinction (special-casing the names? but they could have done that before): print open.__doc__ open(name[, mode[, buffering]]) - file object Open a file using the file() type, returns a file object. print file.__doc__ file(name[, mode[, buffering]]) - file object Open a file. The mode can be 'r', 'w' or 'a' for reading (default), writing or appending. The file will be created if it doesn't exist when opened for writing or appending; it will be truncated when opened for writing. Add a 'b' to the mode for binary files. Add a '+' to the mode to allow simultaneous reading and writing. If the buffering argument is given, 0 means unbuffered, 1 means line buffered, and larger numbers specify the buffer size. Add a 'U' to mode to open the file for input with universal newline support. Any line ending in the input file will be seen as a '\n' in Python. Also, a file so opened gains the attribute 'newlines'; the value for this attribute is one of None (no newline read yet), '\r', '\n', '\r\n' or a tuple containing all the newline types seen. 'U' cannot be combined with 'w' or '+' mode. In Python 2.4, the docstrings were of course the same (the current trunk's file.__doc__ except for a line at the end). Since all useful info about how to open a file has been purged from open()'s docstring, if you've got the intent right, looks like the implementation got it backwards ;-) agreed. imho, the detailed description should be moved to open, and the file docstring should refer to open for a full description of how the arguments are used. and the open docstring could say something like returns a file object. in the current version, this is always an instance of the file() type. unless I'm missing something here, of course. (I was asked to review this patch, but those mails arrived around 2 am, so I didn't see them until now...) /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] More on contextlib - adding back a contextmanager decorator
Guido van Rossum wrote: On 5/1/06, James Y Knight [EMAIL PROTECTED] wrote: Don't forget that the majority of users will never have heard any of these discussions nor have used 2.5a1 or 2.5a2. Choose the best term for them, not for the readers of python-dev. I couldn't agree more! (Another thought, occasionally useful,is to consider that surely the number of Python programs yet to be written, and the number of Python programmers who yet have to learn the language, must surely exceed the current count. At least, one would hope so -- if that's not true, we might as well stop now. :-) If reason 1 had been my only reason for agreeing with Greg, I wouldn't have said anything :) The conflict with 'managed code' and thinking about the number of objects named 'manager' I've seen in different programs were enough to give me pause, though. I've got no real idea as to how we can get a better feel for which terminology would be clearer to people that haven't already been exposed to this topic for months, though :( Nick, do you have it in you to fix PEP 343? Or at least come up with a draft patch? We can take this off-linel with all the +0's and +1's coming in I'm pretty comfortable with this change now, although we should probably wait until later today to commit. I can handle the PEP (just getting rid of __context__ for now). I'll willingly cede the joy of actually fixing SVN to someone else, though :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding functools.decorator
Guido van Rossum wrote:
On 4/30/06, Georg Brandl [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
I expect that at some point people will want to tweak what gets copied
by _update_wrapper() -- e.g. some attributes may need to be
deep-copied, or personalized, or skipped, etc.
What exactly do you have in mind there? If someone wants to achieve this,
she can write his own version of @decorator.
I meant that the provided version should make writing your own easier
than copying the source and editing it. Some form of subclassing might
make sense, or a bunch of smaller functions that can be called for
various actions. You'll probably have to discover some real use cases
before you'll be able to design the right API for this.
Maybe we should just expose a basic interface to replace the four lines of
boilerplate (the docstring makes this look more complicated than it really is!):
WRAPPER_ASSIGNMENTS = ('__module__', '__name__', '__doc__')
WRAPPER_UPDATES = ('__dict__')
def update_wrapper(wrapper, wrapped,
assigned = WRAPPER_ASSIGNMENTS,
updated = WRAPPER_UPDATES):
Update a wrapper function to look like the wrapped function
Attributes of the wrapped function named in the assigned
argument are assigned directly to the corresponding attributes
of the wrapper function.
The update() method of wrapper function attributes named in the
updated argument are called with the corresponding attribute of
the wrapped function as their sole argument.
for attr in assigned:
setattr(wrapper, attr, getattr(wrapped, attr))
for attr in updated:
getattr(wrapper, attr).update(getattr(wrapped, attr))
The two global constants provide clear documentation of the default behaviour
and the keyword arguments make it easy to copy or update a couple of extra
arguments if you need to, or to prevent the standard copying.
Including the return statement allows this to be used as a decorator if you
prefer:
from functools import partial, update_wrapper
@partial(update_wrapper, func)
def wrapper(*args, **kwds):
# wrap func here.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] signature object issues (to discuss while I am out of contact)
Brett Cannon wrote:
One is whether a signature object should be automatically created for
every function. As of right now the PEP I am drafting has it on a
per-need basis and have it assigned to __signature__ through a
built-in function or putting it 'inspect'. Now automatically creating
the object would possibly make it more useful, but it could also be
considered overkill. Also not doing it automatically allows signature
objects to possibly make more sense for classes (to represent
__init__) and instances (to represent __call__). But having that same
support automatically feels off for some reason to me.
My current impulse is to put the signature object in the inspect module to
start with, and don't give it a special attribute at all.
All of the use cases I can think of (introspection for documentation purposes
or argument checking purposes) don't really suffer either way regardless of
whether the signature retrieval is spelt obj.__signature__ or
inspect.getsignature(obj).
Since it doesn't make much difference from a usability point of view, let's
start with the object in the library module first.
The second question is whether it is worth providing a function that
will either figure out if a tuple and dict representing arguments
would work in calling the function. Some have even suggested a
function that returns the actual bindings if the call were to occur.
Personally I don't see a huge use for either, but even less for the
latter version. If people have a legit use case for either please
speak up, otherwise I am tempted to keep the object simple.
A bind method on the signature objects is pretty much essential for any kind
of argument checking usage.
In addition to Aahz's precondition checking example, Talin gave a good example
on the Py3k list of a function decorator for logging all calls to a function,
and including the argument bindings in the log message.
And just in case you think the operation would be easy to implement if you
need it, I've included below the bind method from the signature object I wrote
to play around with the ideas posted to the Py3k list. It took a fair bit of
work to get it to spit out the right answers :)
Cheers,
Nick.
def bind(*args, **kwds):
Return a dict mapping parameter names to bound arguments
self = args[0]
args = args[1:]
bound_params = {}
num_args = len(args)
missing_args = set(self.required_args)
arg_names = self.required_args + self.optional_args
num_names = len(arg_names)
# Handle excess positional arguments
if self.extra_args:
bound_params[self.extra_args] = tuple(args[num_names:])
elif num_args num_names:
self._raise_args_error(num_args)
# Bind positional arguments
for name, value in zip(arg_names, args):
bound_params[name] = value
missing_args -= set((name,))
# Bind keyword arguments (and handle excess)
if self.extra_kwds:
extra_kwds = dict()
bound_params[self.extra_kwds] = extra_kwds
else:
extra_kwds = None
for name, value in kwds.items():
if name in bound_params:
raise TypeError(
Got multiple values for argument '%s' % name)
elif name in arg_names:
missing_args -= set((name,))
bound_params[name] = value
elif extra_kwds is not None:
extra_kwds[name] = value
else:
raise TypeError(
Got unexpected keyword argument '%s' % name)
if missing_args:
self._raise_args_error(num_args)
# All done
return bound_params
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
Terry Reedy wrote:
my way to call your example (given the data in separate variables):
make_person(name, age, phone, location)
your way:
make_person(name=name, age=age, phone=phone, location = location)
For situations like that, I've sometimes thought
it would be useful to be able to say something like
make_person(=name, =age, =phone, =location)
It is a feature of Python that arguments can usually be matched to
parameters either by position or name, as the *caller* chooses.
Except that the caller doesn't always get that option
even now, if the callee has chosen to use *args or **kwds.
So I wouldn't consider that a very strong argument.
And they need not; it is right there in front of them. As for writers,
modern IDEs should try to list the parameter signature upon typing 'func('.
Which is extremely difficult for an IDE to do without
static type information.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] elimination of scope bleeding ofiteration variables
Josiah Carlson wrote: for line in lines: line = line.rstrip() ... I'm generally -0 on the raise a SyntaxError in this particular case, That's a good point. I'm inclined to agree. I think I might have even done something like that recently, but I can't remember the details. and am +0 on the double use below: for x in y: for x in z: Can anyone think of a plausible use case for that? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] elimination of scope bleeding ofiteration variables
Greg Ewing wrote: Josiah Carlson wrote: and am +0 on the double use below: for x in y: for x in z: Can anyone think of a plausible use case for that? This really seems more like the domain of pychecker/pylint rather than the compiler. The code may be a bad idea, but I don't see any reason to make it a syntax error. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] global variable modification in functions [Re: elimination of scope bleeding of iteration variables]
Phillip J. Eby wrote: And for the case where the compiler can tell the variable is accessed before it's defined, there's definitely something wrong. This code, for example, is definitely missing a global and the compiler could in principle tell: foo = 1 def bar(): foo+=1 So I see no problem (in principle, as opposed to implementation) with issuing a warning or even a compilation error for that code. (And it's wrong even if the snippet I showed is in a nested function definition, although the error would be different.) If I recall correctly, the new compiler uses a control-flow graph that could possibly be used to determine whether there is a path on which a local could be read before it's stored. I think symtable.c could wander back up the lexical block stack checking that target names are defined for augmented assignment statements. That said, while I'd be happy to review a patch, I'm not going to try to write one :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] elimination of scope bleeding ofiteration variables
On Tue, May 02, 2006, Nick Coghlan wrote: Greg Ewing wrote: Josiah Carlson wrote: and am +0 on the double use below: for x in y: for x in z: Can anyone think of a plausible use case for that? This really seems more like the domain of pychecker/pylint rather than the compiler. The code may be a bad idea, but I don't see any reason to make it a syntax error. My sentiments precisely. Unless someone can come up with a good reason for changing the current semantics, I'm -1. Side note: if people do want to continue discussing this, I think it should go to python-3000. There is absolutely no reason to break currently-running code that happens to use this pattern. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ Argue for your limitations, and sure enough they're yours. --Richard Bach ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Date for DC-area Python sprint?
I'm working on setting up a sprint in the Washington DC area; currently I have a lead that would be in Arlington. I'd like to discuss the date on python-dev in order to coordinate with other events. The sprint has no particular goal, so people might just hack on their core-related projects. It certainly doesn't need to be limited to core Python; if space is available, people could certainly come to work on other projects. I'm thinking May 27th might be a good date. The Need For Speed sprint is May 21-28 (Sunday to Sunday), so the DC-area people can coordinate with the other sprinters via IRC. On the 21st the Need For Speed sprinters might be scattered, with people still arriving; on the 28th people will be leaving. The 27th seems like a good compromise (though maybe everyone in Iceland will be burnt out by that point). Also, does someone want to organize a bug day for the same date, or a sprint on the West Coast or in the Midwest? --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r45850 - in python/trunk: Doc/lib/libfuncs.tex Lib/test/test_subprocess.py Misc/NEWS Objects/fileobject.c Python/bltinmodule.c
On Tue, May 02, 2006, Tim Peters wrote: Author: neal.norwitz Date: Tue May 2 06:43:14 2006 New Revision: 45850 Modified: python/trunk/Lib/test/test_subprocess.py python/trunk/Objects/fileobject.c python/trunk/Python/bltinmodule.c Log: SF #1479181: split open() and file() from being aliases for each other. Umm ... why? I suppose I wouldn't care, except it left test_subprocess failing on all the Windows buildbots, and I don't feel like figuring out why. To a first approximation, test_universal_newlines_communicate() now takes the # Interpreter without universal newline support branch on Windows, but shouldn't. That's a bug in the Windows implementation or in the docs. test_subprocess failed because open() was no longer an alias for file(); I originally planned to just s/open/file/ but when I read the docs, the docs said that newlines attribute was supposed to go on file objects, not the file type. Neal's decision to use my original idea is probably fine, but I'm not sure. http://docs.python.org/dev/lib/bltin-file-objects.html I'll answer your other post later when I have more time, but you might check http://mail.python.org/pipermail/python-dev/2005-December/thread.html#59073 for the basic history. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ Argue for your limitations, and sure enough they're yours. --Richard Bach ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] More on contextlib - adding back a contextmanager decorator
On 5/2/06, Nick Coghlan [EMAIL PROTECTED] wrote: Nick, do you have it in you to fix PEP 343? Or at least come up with a draft patch? We can take this off-linel with all the +0's and +1's coming in I'm pretty comfortable with this change now, although we should probably wait until later today to commit. I can handle the PEP (just getting rid of __context__ for now). I'll willingly cede the joy of actually fixing SVN to someone else, though :) OK, if you fix the PEP, I'll fix the code to match; I added most of those __context__ methods so I can delete them. Unless someone else beats me to it. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
On 5/2/06, Greg Ewing [EMAIL PROTECTED] wrote: Terry Reedy wrote: my way to call your example (given the data in separate variables): make_person(name, age, phone, location) your way: make_person(name=name, age=age, phone=phone, location = location) For situations like that, I've sometimes thought it would be useful to be able to say something like make_person(=name, =age, =phone, =location) And even with Terry's use case quoted I can't make out what you meant that to do. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] more pyref: a better term for string conversion
Guido van Rossum wrote: Backticks certainly are deprecated -- Py3k won't have them (nor will they become available for other syntax; they are undesirable characters due to font issues and the tendency of word processing tools to generate backticks in certain cases where you type forward ticks). And would it be acceptable for 2.5 to issue a DeprecationWarning for backticks? Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] more pyref: a better term for string conversion
Georg Brandl wrote: Guido van Rossum wrote: Backticks certainly are deprecated -- Py3k won't have them (nor will they become available for other syntax; they are undesirable characters due to font issues and the tendency of word processing tools to generate backticks in certain cases where you type forward ticks). And would it be acceptable for 2.5 to issue a DeprecationWarning for backticks? No. Backticks do not disappear until Py3.0 and we're not going to muck-up the 2.x series with warnings and deprecations for everything that is going to change in Py3.0. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] test failures in test_ctypes (HEAD)
I see test failures in current HEAD on my Google Red Hat Linux desktop that the buildbots don't seem to have: ./python -E -tt ../Lib/test/regrtest.py test_ctypes test_ctypes test test_ctypes failed -- errors occurred; run in verbose mode for details More details from running this manually: $ ./python ../Lib/test/test_ctypes.py . . (lots of passing tests; then:) . test_gl (ctypes.test.test_find.Test_OpenGL_libs) ... ERROR test_glu (ctypes.test.test_find.Test_OpenGL_libs) ... ERROR test_glut (ctypes.test.test_find.Test_OpenGL_libs) ... ERROR == ERROR: test_gl (ctypes.test.test_find.Test_OpenGL_libs) -- Traceback (most recent call last): File /home/guido/projects/python/trunk/Lib/ctypes/test/test_find.py, line 42, in setUp self.glut = CDLL(lib_glut) File /home/guido/projects/python/trunk/Lib/ctypes/__init__.py, line 288, in __init__ self._handle = _dlopen(self._name, mode) OSError: /usr/lib/libglut.so.3: undefined symbol: XGetExtensionVersion == ERROR: test_glu (ctypes.test.test_find.Test_OpenGL_libs) -- Traceback (most recent call last): File /home/guido/projects/python/trunk/Lib/ctypes/test/test_find.py, line 42, in setUp self.glut = CDLL(lib_glut) File /home/guido/projects/python/trunk/Lib/ctypes/__init__.py, line 288, in __init__ self._handle = _dlopen(self._name, mode) OSError: /usr/lib/libglut.so.3: undefined symbol: XGetExtensionVersion == ERROR: test_glut (ctypes.test.test_find.Test_OpenGL_libs) -- Traceback (most recent call last): File /home/guido/projects/python/trunk/Lib/ctypes/test/test_find.py, line 42, in setUp self.glut = CDLL(lib_glut) File /home/guido/projects/python/trunk/Lib/ctypes/__init__.py, line 288, in __init__ self._handle = _dlopen(self._name, mode) OSError: /usr/lib/libglut.so.3: undefined symbol: XGetExtensionVersion -- This seems libglut related -- I don't know what that is but find /lib /usr/lib -name \*glut\* produces this output: /usr/lib/libglut.so.3 /usr/lib/libglut.so.3.7 -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Positional-only Arguments
I've not followed the PEP 3102 (keyword-only arguments) discussion closely enough to know if this has been mentioned, but we were discussing a need at work today for the ability to enforce position-only arguments. The specific instance was an argument that was intended to be used as a positional argument which a group had began using as a keyword argument instead. There was no way for the users to know it was intended for positional use only. And it makes refactoring the signature difficult. Of course you could use *args from the get-go, but ugly signatures as default isn't nice. Is there any reason to pursue the idea, or this mostly a misguided desire for symmetry? -- Benji York ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test failures in test_ctypes (HEAD)
Guido van Rossum wrote: I see test failures in current HEAD on my Google Red Hat Linux desktop that the buildbots don't seem to have: ./python -E -tt ../Lib/test/regrtest.py test_ctypes test_ctypes test test_ctypes failed -- errors occurred; run in verbose mode for details More details from running this manually: $ ./python ../Lib/test/test_ctypes.py . . (lots of passing tests; then:) . test_gl (ctypes.test.test_find.Test_OpenGL_libs) ... ERROR test_glu (ctypes.test.test_find.Test_OpenGL_libs) ... ERROR test_glut (ctypes.test.test_find.Test_OpenGL_libs) ... ERROR == ERROR: test_gl (ctypes.test.test_find.Test_OpenGL_libs) -- Traceback (most recent call last): File /home/guido/projects/python/trunk/Lib/ctypes/test/test_find.py, line 42, in setUp self.glut = CDLL(lib_glut) File /home/guido/projects/python/trunk/Lib/ctypes/__init__.py, line 288, in __init__ self._handle = _dlopen(self._name, mode) OSError: /usr/lib/libglut.so.3: undefined symbol: XGetExtensionVersion You might be interested in https://sourceforge.net/tracker/?func=detailatid=105470aid=1478253group_id=5470 Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test failures in test_ctypes (HEAD)
Guido van Rossum wrote: I see test failures in current HEAD on my Google Red Hat Linux desktop that the buildbots don't seem to have: ./python -E -tt ../Lib/test/regrtest.py test_ctypes test_ctypes test test_ctypes failed -- errors occurred; run in verbose mode for details More details from running this manually: $ ./python ../Lib/test/test_ctypes.py . . (lots of passing tests; then:) . test_gl (ctypes.test.test_find.Test_OpenGL_libs) ... ERROR test_glu (ctypes.test.test_find.Test_OpenGL_libs) ... ERROR test_glut (ctypes.test.test_find.Test_OpenGL_libs) ... ERROR Can you try this patch for Lib/ctypes/test/test_find, please? Index: test_find.py === --- test_find.py(Revision 45791) +++ test_find.py(Arbeitskopie) @@ -39,9 +39,9 @@ if lib_glu: self.glu = CDLL(lib_glu, RTLD_GLOBAL) if lib_glut: -self.glut = CDLL(lib_glut) +self.glut = CDLL(lib_glut, RTLD_GLOBAL) if lib_gle: -self.gle = CDLL(lib_gle) +self.gle = CDLL(lib_gle, RTLD_GLOBAL) if lib_gl: def test_gl(self): The test should try to test the RTLD_GLOBAL flag for loading shared libs. (The patch is pure guesswork, inspired by a recent thread on the ctypes-users list. It would be great if someone could provide some insight into this, or suggest a better test). Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] signature object issues (to discuss while I am out of contact)
On 5/2/06, Nick Coghlan [EMAIL PROTECTED] wrote:
Brett Cannon wrote:
One is whether a signature object should be automatically created for
every function. As of right now the PEP I am drafting has it on a
per-need basis and have it assigned to __signature__ through a
built-in function or putting it 'inspect'. Now automatically creating
the object would possibly make it more useful, but it could also be
considered overkill. Also not doing it automatically allows signature
objects to possibly make more sense for classes (to represent
__init__) and instances (to represent __call__). But having that same
support automatically feels off for some reason to me.
My current impulse is to put the signature object in the inspect module to
start with, and don't give it a special attribute at all.
All of the use cases I can think of (introspection for documentation purposes
or argument checking purposes) don't really suffer either way regardless of
whether the signature retrieval is spelt obj.__signature__ or
inspect.getsignature(obj).
It does for decorators. How do you make sure that a decorator uses
the signature object of the wrapped function instead of the decorator?
Or are you saying to just not worry about that right now?
Since it doesn't make much difference from a usability point of view, let's
start with the object in the library module first.
The second question is whether it is worth providing a function that
will either figure out if a tuple and dict representing arguments
would work in calling the function. Some have even suggested a
function that returns the actual bindings if the call were to occur.
Personally I don't see a huge use for either, but even less for the
latter version. If people have a legit use case for either please
speak up, otherwise I am tempted to keep the object simple.
A bind method on the signature objects is pretty much essential for any kind
of argument checking usage.
In addition to Aahz's precondition checking example, Talin gave a good example
on the Py3k list of a function decorator for logging all calls to a function,
and including the argument bindings in the log message.
And just in case you think the operation would be easy to implement if you
need it, I've included below the bind method from the signature object I wrote
to play around with the ideas posted to the Py3k list. It took a fair bit of
work to get it to spit out the right answers :)
Thanks, Nick!
-Brett
Cheers,
Nick.
def bind(*args, **kwds):
Return a dict mapping parameter names to bound arguments
self = args[0]
args = args[1:]
bound_params = {}
num_args = len(args)
missing_args = set(self.required_args)
arg_names = self.required_args + self.optional_args
num_names = len(arg_names)
# Handle excess positional arguments
if self.extra_args:
bound_params[self.extra_args] = tuple(args[num_names:])
elif num_args num_names:
self._raise_args_error(num_args)
# Bind positional arguments
for name, value in zip(arg_names, args):
bound_params[name] = value
missing_args -= set((name,))
# Bind keyword arguments (and handle excess)
if self.extra_kwds:
extra_kwds = dict()
bound_params[self.extra_kwds] = extra_kwds
else:
extra_kwds = None
for name, value in kwds.items():
if name in bound_params:
raise TypeError(
Got multiple values for argument '%s' % name)
elif name in arg_names:
missing_args -= set((name,))
bound_params[name] = value
elif extra_kwds is not None:
extra_kwds[name] = value
else:
raise TypeError(
Got unexpected keyword argument '%s' % name)
if missing_args:
self._raise_args_error(num_args)
# All done
return bound_params
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Positional-only Arguments
Benji York [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I've not followed the PEP 3102 (keyword-only arguments) discussion closely enough to know if this has been mentioned, but we were discussing a need at work today for the ability to enforce position-only arguments. You could discourage name use by not documenting the actual, internal name of the parameters. Something like def weather_guess(temp, pres): '''Guess weather from temperature in degrees Kelvin and pressure in millibars passed by position in that order.''' Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
In article [EMAIL PROTECTED], Guido van Rossum [EMAIL PROTECTED] wrote: On 5/2/06, Greg Ewing [EMAIL PROTECTED] wrote: Terry Reedy wrote: my way to call your example (given the data in separate variables): make_person(name, age, phone, location) your way: make_person(name=name, age=age, phone=phone, location = location) For situations like that, I've sometimes thought it would be useful to be able to say something like make_person(=name, =age, =phone, =location) And even with Terry's use case quoted I can't make out what you meant that to do. I'm pretty sure he wants it to mean: make_person(name=name, age=age, phone=phone, location=location). In other words it's a shortcut to avoid needless repetition. Personally I'd like some way to do that, but the initial = is pretty startling at first glance. Not that I have a better suggestion. As far as the rest of the thread goes (and I may be late to the party on this), I personally would *love* to be able to write: def func(arg0, arg1, *args, key1=def1) and force key1 to be specified by name. I've coded this before using **kargs for the keyword-only args, but I'd much rather be able to list them in the def (making it more self-documenting). But that's as far as I'd take it. I don't see the point to keyword-only arguments that do not have default values. And I don't think it's worth the potential confusion to allow keyword-only args after a fixed # of positional args. The proposed syntax reads like exactly the wrong thing to me; | as a separator might do if one is desperate enough for this feature, i.e.: def foo(arg0, arg1 | karg=None): -- Russell ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Positional-only Arguments
Terry Reedy wrote: You could discourage name use by not documenting the actual, internal name of the parameters. The issue we had was that the name wasn't documented at all, the users simply looked at the code and began using the keyword name. This may well be an area where we're all adults here wins. OTOH there is a /slight/ possibility that it'd be better to disallow using an argument as a keyword unless explicitly flagged as such. Similar to how the C API works now. This has the same advantages of the keyword-only PEP (3102): tools will know which arguments are positional and which are keyword. Doing so would recast PEP 3102 from how to get a keyword-only argument into how to get a keyword (non-positional) argument. A downside would be the need to specify when an argument can be positional *or* keyword. -- Benji York ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Positional-only Arguments
Guido van Rossum wrote: I've used a double leading underscore on the name. Works great for methods! We discussed that. My main issue with that is that it's possible/likely that all arguments should be positional by default, should they all then begin with underscores? Makes for ugly function bodies (or lots of name rebinding). -- Benji York ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] mail to talin is bouncing
Sorry to bother the list -- talin, mail to you is bouncing: - The following addresses had permanent fatal errors - [EMAIL PROTECTED] - Transcript of session follows - ... while talking to viridia.org RCPT To:[EMAIL PROTECTED] 550 message to verify they are valid. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] elimination of scope bleeding ofiteration variables
Josiah Carlson wrote: for line in lines: line = line.rstrip() ... Exactly the use case I was thinking of (and one I used yesterday BTW). I'm -1 on *dis*allowing reusing a name bound in a for loop in any construct i.e. +1 for the status quo. Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] elimination of scope bleeding ofiteration variables
Don't worry. This isn't going to change. Someone please update PEP 3099. On 5/2/06, Delaney, Timothy (Tim) [EMAIL PROTECTED] wrote: Josiah Carlson wrote: for line in lines: line = line.rstrip() ... Exactly the use case I was thinking of (and one I used yesterday BTW). I'm -1 on *dis*allowing reusing a name bound in a for loop in any construct i.e. +1 for the status quo. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
Guido van Rossum wrote: On 5/2/06, Greg Ewing [EMAIL PROTECTED] wrote: make_person(=name, =age, =phone, =location) And even with Terry's use case quoted I can't make out what you meant that to do. I meant it to do the same thing as make_person(name=name, age=age, phone=phone, location=location) I come across use cases for this fairly frequently, usually when I have an __init__ method that supplies default values for a bunch of arguments, and then wants to pass them on to an inherited __init__ with the same names. It feels very wanky having to write out all those foo=foo expressions. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
On 5/2/06, Greg Ewing [EMAIL PROTECTED] wrote: Guido van Rossum wrote: On 5/2/06, Greg Ewing [EMAIL PROTECTED] wrote: make_person(=name, =age, =phone, =location) And even with Terry's use case quoted I can't make out what you meant that to do. I meant it to do the same thing as make_person(name=name, age=age, phone=phone, location=location) I come across use cases for this fairly frequently, usually when I have an __init__ method that supplies default values for a bunch of arguments, and then wants to pass them on to an inherited __init__ with the same names. It feels very wanky having to write out all those foo=foo expressions. Sorry, but leading = signs feel even more wanky. (That's a technical term. ;-) It violates the guideline that Python's punctuation should preferably mimic English; or other mainstram languages (as with 'x.y' and '@deco'). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
On Tuesday 02 May 2006 22:32, Guido van Rossum wrote: and '@deco'). Pronounced at-deck-oh, @deco is an art-deco variant favored in r-deprived regions. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
