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(file) 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] 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...) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding functools.decorator
On 5/2/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > 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!): +1 -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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=detail&atid=105470&aid=1478253&group_id=5470 Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any reason that any()/all() do not takea predicateargument?
> > How about this? > > > > if any(x==5 for x in seq): > > Aren't all of these equivalent to: > > if 5 in seq: > ... Of course. However, the original example was pretty clearly intended to be an illustrative instance of a more general problem. Rewriting the example as any(x==5 for x in seq) preserves the generality; rewriting it as 5 in seq doesn't. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Positional-only Arguments
I've used a double leading underscore on the name. Works great for methods! On 5/2/06, Terry Reedy <[EMAIL PROTECTED]> wrote: > > "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 > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Alternative path suggestion
Hello,
I saw the discussion about including the path type in the standard
library. As it turned out, I recently wrote a program which does quite
a lot of path manipulation. This caused me to think that the proposed
path module:
* Makes path manipulation significantly easier
* Can be improved.
So I tried to write my version of it. My basic problem with the
current proposed path module is that it's a bit... messy. It contains
a lot of methods, collected from various modules, and for me it looks
too crowded - there are too many methods and too many details for me
to easily learn.
So I tried to organize it all. I think that the result may make file
and path manipulation really easier.
Here are my ideas. It's a copy of what I posted a few minutes ago in
the wiki - you can view it at
http://wiki.python.org/moin/AlternativePathClass (it looks better
there).
You can find the implementation at
http://wiki.python.org/moin/AlternativePathModule?action=raw
(By the way, is there some "code wiki" available? It can simply be a
public svn repository. I think it will be useful for those things.)
All these are ideas - I would like to hear what you think about them.
= Major Changes =
== a tuple instead of a string ==
The biggest conceptual change is that my path object is a subclass of
''tuple'', not a subclass of str. For example,
{{{
>>> tuple(path('a/b/c'))
('a', 'b', 'c')
>>> tuple(path('/a/b/c'))
(path.ROOT, 'a', 'b', 'c')
}}}
This means that path objects aren't the string representation of a
path; they are a ''logical'' representation of a path. Remember why a
filesystem path is called a path - because it's a way to get from one
place on the filesystem to another. Paths can be relative, which means
that they don't define from where to start the walk, and can be not
relative, which means that they do. In the tuple representation,
relative paths are simply tuples of strings, and not relative paths
are tuples of strings with a first "root" element.
The advantage of using a logical representation is that you can forget
about the textual representation, which can be really complex. You
don't have to call normpath when you're unsure about how a path looks,
you don't have to search for seps and altseps, and... you don't need
to remember a lot of names of functions or methods. To show that, take
a look at those methods from the original path class and their
equivalent in my path class:
{{{
p.normpath() -> Isn't needed - done by the constructor
p.basename() -> p[-1]
p.splitpath() -> (p[:-1], p[-1])
p.splitunc() -> (p[0], p[1:]) (if isinstance(p[0], path.UNCRoot))
p.splitall() -> Isn't needed
p.parent -> p[:-1]
p.name-> p[-1]
p.drive -> p[0] (if isinstance(p[0], path.Drive))
p.uncshare-> p[0] (if isinstance(p[0], path.UNCRoot))
and of course:
p.join(q) [or anything like it] -> p + q
}}}
The only drawback I can see in using a logical representation is that
giving a path object to functions which expect a path string won't
work. The immediate solution is to simply use str(p) instead of p. The
long-term solution is to make all related functions accept a path
object.
Having a logical representation of a path calls for a bit of term
clearing-up. What's an absolute path? On POSIX, it's very simple: a
path starting with a '/'. But what about Windows? Is "\temp\file" an
absolute path? I claim that it isn't really. The reason is that if you
change the current working directory, its meaning changes: It's now
not "c:\temp\file", but "a:\temp\file". The same goes for
"c:temp\file". So I decided on these two definitions:
* A ''relative path'' is a path without a root element, so it can be
concatenated to other paths.
* An ''absolute path'' is a path whose meaning doesn't change when
the current working directory changes.
This means that paths starting with a drive letter alone
(!UnrootedDrive instance, in my module) and paths starting with a
backslash alone (the CURROOT object, in my module) are not relative
and not absolute.
I really think that it's a better way to handle paths. If you want an
example, compare the current implementation of relpathto and my
implementation.
== Easier attributes for stat objects ==
The current path objects includes:
* isdir, isfile, islink, and -
* atime, mtime, ctime, size.
The first line does file mode checking, and the second simply gives
attributes from the stat object.
I suggest that these should be added to the stat_result object. isdir,
isfile and islink are true if a specific bit in st_mode is set, and
atime, mtime, ctime and size are simply other names for st_atime,
st_mtime, st_ctime and st_size.
It means that instead of using the atime, mtime etc. methods, you will
write {{{ p.stat().atime }}}, {{{ p.stat().size }}}, etc.
This is good, because:
* If you want to make only one system call, it's very easy to save
the stat object and use it.
* If you have to deal with symbolic links, you can simply use {{{
p.lstat().mtime }}}. Yes, symbolic link
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 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. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] more pyref: continue in finally statements
On 5/1/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > then what should be the meaning of "continue" here? The finally > block *eventually* needs to re-raise the exception. When should > that happen? It should behave similarly to return and swallow the exception. In your example this would result in an infinite loop. Alternately the behavior of return should be changed, and the below code would no longer work as it does today. >>> def foo(): ... try: raise Exception ... finally: return 'Done' ... >>> foo() 'Done' Michael -- Michael Urman http://www.tortall.net/mu/blog ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
