Re: [Python-Dev] standard library mimetypes module pathologically broken?
Georg Brandl wrote: > Nick Coghlan schrieb: >> P.S. For anyone else that is slow like me, take a close look at PEP 387... > > What should we see, other than that we have two PEPs on the same topic that > should be merged? Benjamin wrote the second one, so he obviously knows there's a written deprecation policy in place, and hence his mini-rant probably wasn't meant to be taken literally - a point I completely missed on first reading. I agree the two PEPs should probably be consolidated into one, but absent a volunteer for that task, leaving them as is doesn't really hurt anything. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] request for comments - standardization of python's purelib and platlib
On Thu, Aug 13, 2009 at 9:22 PM, Brett Cannon wrote: > > > On Thu, Aug 13, 2009 at 11:23, Jan Matejek wrote: >> >> Hello, >> >> I'm cross-posting this to distributi...@freedesktop and python-dev, >> because the topic is relevant to both groups and should be solved in >> cooperation. >> >> The issue: >> >> In Python's default configuration (on linux), both purelib (location for >> pure python modules) and platlib (location for platform-dependent binary >> extensions) point to $prefix/lib/pythonX.Y/site-packages. >> That is no good for two main reasons. >> >> One, python depends on the "lib" directory. (from distro's point of >> view, prefix is /usr, so let's talk /usr/lib) Due to this, it's >> impossible to install python under /usr/lib64 without heavy patching. >> Repeated attempts to bring python developers to acknowledge and rectify >> the situation have all failed (common argument here is "that would mean >> redesign of distutils and huge parts of whatnot"). > > This is now Tarek's call, so this may or may not have changed in terms of > what the (now) distutils maintainer thinks. > I don't recall those repeated attempts , but I've been around for less than two years. You are very welcome to come in the Distutils-SIG ML to discuss these matters. I'm moving the discussion there. Among the proposals you have detailed, the sharedir way seems like the most simple/interesting one (depending on you answer to Brett's question ) Regards Tarek -- Tarek Ziadé | http://ziade.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
[Python-Dev] Tkinter: modify xview of entry widget
Hi, I'm Paolo from Italy and I'm a python user. I wish to propose a useful and smart method modify in Tkinter Library: Previously to scroll this widget we had to write an external function (recalling xview_moveto and xview_scroll). With my method this operation is cleared and the same as all other widgets (just have to call xview). -- Modify Proposal: -- Change the method xview of entry so it works as all widget scrollable, and it's compatible with 'old' xview. So to scroll entry widget: entry_widget['xscrollcommand']=scroll_widget.set scroll_widget['command']=entry_widget.xview The change in module Tkinter is: def xview(self,*args): """Query and change horizontal position of the view.""" #modify if not args: return self._getdoubles(self.tk.call(self._w, 'xview')) #old code index=args[0] self.tk.call(self._w, 'xview', index) -- I wish that this implementation could be integrated in Tkinter, and I remain at disposal for any question or further information. Waiting for your response, Best regards Paolo Fraguglia ___ 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] Tkinter: modify xview of entry widget
paolo.fr...@libero.it wrote: Hi, I'm Paolo from Italy and I'm a python user. I wish to propose a useful and smart method modify in Tkinter Library: Hi Paolo, Can you create an issue on the bug tracker - with the patch attached. Your suggestion stands a much better chance if this patch includes tests and documentation. All the best, Michael Foord Previously to scroll this widget we had to write an external function (recalling xview_moveto and xview_scroll). With my method this operation is cleared and the same as all other widgets (just have to call xview). -- Modify Proposal: -- Change the method xview of entry so it works as all widget scrollable, and it's compatible with 'old' xview. So to scroll entry widget: entry_widget['xscrollcommand']=scroll_widget.set scroll_widget['command']=entry_widget.xview The change in module Tkinter is: def xview(self,*args): """Query and change horizontal position of the view.""" #modify if not args: return self._getdoubles(self.tk.call(self._w, 'xview')) #old code index=args[0] self.tk.call(self._w, 'xview', index) -- I wish that this implementation could be integrated in Tkinter, and I remain at disposal for any question or further information. Waiting for your response, Best regards Paolo Fraguglia ___ 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/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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] Tkinter: modify xview of entry widget
2009/8/14 paolo.fr...@libero.it : > Hi, > I'm Paolo from Italy and I'm a python user. > I wish to propose a useful and smart method modify in Tkinter Library: > > Previously to scroll this widget we had to write an external function > (recalling xview_moveto and xview_scroll). > > With my method this operation is cleared and the same as all other widgets > (just have to call xview). > > I wish that this implementation could be integrated in Tkinter, and I remain > at disposal for any question or further information. > > Waiting for your response, I believe you are trying to mention the fact that the Entry.xview method doesn't allow being called without passing an index, even if this index is None. Is that the case ? Take a look on http://bugs.python.org/issue1135 and http://bugs.python.org/issue6180, they already address this fix. > Best regards > Paolo Fraguglia Regards, -- -- Guilherme H. Polo Goncalves ___ 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] Tweaking AST lineno and col_offset
Hi all, Off and on I have been directly comparing Jython's AST with Python's AST and generally working towards making them as close to identical as possible. There are a couple of places where I haven't "fixed" Jython because it looks to me like Jython has slightly better offsets. One example: for a,b in c: pass The Tuple node "a,b" ends up with a col_offset of 0 (the position of the "for") where Jython has the col_offset as 4 (the position of "a"). Jython's result is more consistent with other Tuple node col_offset results. I have a local patch that changes the CPython col_offset to match Jython's, but before I submit a patch I thought I'd ask here if there is support for this sort of change and if I should continue to find col_offset and lineno results that look fishy to me, or should I just change Jython's results to match (one way or another, things will be much easier for me to test if they match). Also, would this be a change that would be considered a backwards incompatibility? In other words, would patches like this be allowed in 2.6/3.1 or only in 2.7/3.2. Regards, -Frank ___ 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] Summary of Python tracker Issues
ACTIVITY SUMMARY (08/07/09 - 08/14/09) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2329 open (+26) / 16195 closed ( +8) / 18524 total (+34) Open issues with patches: 925 Average duration of open issues: 659 days. Median duration of open issues: 414 days. Open Issues Breakdown open 2297 (+26) pending31 ( +0) Issues Created Or Reopened (34) ___ TarFile.getmembers fails at struct.unpack: unpack requires a str 08/07/09 http://bugs.python.org/issue6669created srid Printing the 'The Python Tutorial' 08/08/09 http://bugs.python.org/issue6670created brimac webbrowser.py doesn't respect xfce default browser 08/09/09 http://bugs.python.org/issue6671created ava1ar patch Add Mingw recognition to pyport.h to allow building extensions 08/09/09 http://bugs.python.org/issue6672created f0k Py3.1 hangs in coroutine and eats up all memory 08/09/09 CLOSED http://bugs.python.org/issue6673created scoder Fatal error: deallocating None 08/10/09 CLOSED http://bugs.python.org/issue6674created shashi inf == inf (wrong IEEE 754 behaviour)08/10/09 CLOSED http://bugs.python.org/issue6675created Cyborg16 expat parser throws Memory Error when parsing multiple files 08/10/09 http://bugs.python.org/issue6676created realpolitik Place the term "delete" within the documentation for os.remove() 08/10/09 http://bugs.python.org/issue6677created mcow inspect.currentframe documentation omits optional depth paramete 08/10/09 http://bugs.python.org/issue6678created llimllib obsolete paragraph in re doc for re.sub 08/10/09 CLOSED http://bugs.python.org/issue6679created MLModel Python 3.1 fails to build when db.h contains non-UTF-8 character 08/10/09 CLOSED http://bugs.python.org/issue6680created Arfrever patch email.parser clips trailing \n of multipart/mixed part if part e 08/10/09 http://bugs.python.org/issue6681created gvanrossum Default traceback does not handle PEP302 loaded modules 08/11/09 http://bugs.python.org/issue6682created anders.blomd...@control.lth.se smtplib authentication - try all mechanisms 08/11/09 http://bugs.python.org/issue6683created shubes "x / 1" and "x * 1" should return x 08/11/09 CLOSED http://bugs.python.org/issue6684created mrjbq7 CGI module documentation references method 'toupper'; should be 08/11/09 http://bugs.python.org/issue6685created troy xml.sax.xmlreader.XMLReader.getProperty (xml.sax.handler.propert 08/11/09 http://bugs.python.org/issue6686created cms103 patch Move the special-case for integer objects out of PyBytes_FromObj 08/11/09 http://bugs.python.org/issue6687created alexandre.vassalotti patch, 26backport
Re: [Python-Dev] request for comments - standardization of python's purelib and platlib
Dne 13.8.2009 21:22, Brett Cannon napsal(a): > On Thu, Aug 13, 2009 at 11:23, Jan Matejek wrote: >> 1 - the traditional way >> purelib = /usr/lib/pythonX.Y/site-packages >> platlib = /usr/lib(64)/pythonX.Y/site-packages >> > > Why can't pure libraries go into lib64 as well? There is nothing saying that > a pure Python package won't have a setup.py that installs different files > based on whether it is for a 32-bit or 64-bit CPython install. What i'd like to accomplish is to have pure "noarch" package that can be installed unchanged into 32bit or 64bit (or 256bit) system, and the respective python would still find the files. Or, to put it another way, a package that can be installed into a multiarch system and be recognized by pythons of all architectures (assuming they are the same version, of course). If the distutils package installs different pure files for 32bit and 64bit python, then it can't be "noarch", so it doesn't matter if it goes into lib64. Also, such package would break this particular scheme - in the situation where the user installs only 32bit version of such package and tries to run it with 64bit python, it will probably break in some weird way. Last but not least, i'd argue that if a python-only package installs different files for different platforms, it is platform-dependent and therefore not pure ;) >> 2 - the sharedir way >> purelib = /usr/share/python/X.Y >> platlib = /usr/lib(64)/pythonX.Y/site-packages > > > Now are you proposing that packages that have both Python source and > extensions be split based on the type of files, or that only pure Python > packages go to /usr/share/python and any packages that are mixed go into > lib(64)? If you are proposing the latter this is more reasonable as the > former will require using .pth files to get import to search both locations > for files in the same package and that just feels icky to me. The latter. Assume no change to "normal" distutils mechanism, only setting the default paths. (for now anyway) regards m. ___ 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] Tweaking AST lineno and col_offset
2009/8/14 Frank Wierzbicki : > Hi all, > > Off and on I have been directly comparing Jython's AST with Python's > AST and generally working towards making them as close to identical as > possible. There are a couple of places where I haven't "fixed" Jython > because it looks to me like Jython has slightly better offsets. One > example: > > for a,b in c: > pass > > The Tuple node "a,b" ends up with a col_offset of 0 (the position of > the "for") where Jython has the col_offset as 4 (the position of "a"). > Jython's result is more consistent with other Tuple node col_offset > results. > > I have a local patch that changes the CPython col_offset to match > Jython's, but before I submit a patch I thought I'd ask here if there > is support for this sort of change and if I should continue to find > col_offset and lineno results that look fishy to me, or should I just > change Jython's results to match (one way or another, things will be > much easier for me to test if they match). Yes, please submit it. > > Also, would this be a change that would be considered a backwards > incompatibility? In other words, would patches like this be allowed > in 2.6/3.1 or only in 2.7/3.2. While I don't see a problem in backporting it to maintence branches, I would personally only apply it to the current development branches. It doesn't seem to fix a "bug", just make a nice improvement. -- Regards, Benjamin ___ 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] expy: an expressway to extend Python
--- On Sat, 8/8/09, Stefan Behnel wrote: > From: Stefan Behnel > Subject: Re: [Python-Dev] expy: an expressway to extend Python > To: python-dev@python.org > Date: Saturday, August 8, 2009, 4:55 PM > > More details at http://expy.sourceforge.net/ > > I'm clearly biased, but my main concern here is that expy > requires C code > to be written inside of strings. There isn't any good > editor support for > that, so I doubt that expy is good for anything but very > thin wrappers (as > in the examples you presented). Thanks a lot for the input -- I sort of recaptured the advantages of expy and listed four points in the new introduction at http://expy.sf.net/ homepage. Lacking of editor highlight support is quite a problem, but it is possible to create a support. For example, you can use this to indicate the start of embedded code highlight: return """ and then the end mark is of course the enclosing """ > > That said, you might want to look at the argument unpacking > code generated > by Cython. It's highly optimised through specialisation and > has been > benchmarked quite a bit faster than the generic Python > C-API functions for > tuple/keyword extracting. Since argument conversion seems > to be more or > less all that expy really does, maybe you want to reuse > that code. > > Stefan Oh sure, that's nice if that part can be adopted by expy-cxpy. Any help out on this would be very welcomed. Yingjie ___ 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] functools.compose to chain functions together
I'd like to express additional interest in python patch 1660179, discussed
here:
http://mail.python.org/pipermail/patches/2007-February/021687.html
On several occasions, I've had the desire for something like this. I've
made due with lambda functions, but as was mentioned, the lambda is clumsy
and harder to read than functools.compose would be.
A potentially common use-case is when a library has a multi-decorator use
case in which they want to compose a meta decorator out of one or more
individual decorators.
Consider the hypothetical library.
# we have three decorators we use commonly
def dec_register_function_for_x(func):
# do something with func
return func
def dec_alter_docstring(func):
# do something to func.__doc__
return func
def inject_some_data(data):
def dec_inject_data(func):
func.data = data # this may not be legal,
but assume it does something useful
return func
return dec_inject_data
# we could use these decorators explicitly throughout our project
@dec_register_function_for_x
@dec_alter_docstring
@dec_inject_some_data('foo data 1')
def our_func_1(params):
pass
@dec_register_function_for_x
@dec_alter_docstring
@dec_inject_some_data('foo data 2')
def our_func_2(params):
pass
For two functions, that's not too onerous, but if it's used throughout the
application, it would be nice to abstract the collection of decorators. One
could do this with lambdas.
def meta_decorator(data):
return lambda func:
dec_register_function_for_x(dec_alter_docstring(dec_inject_some_data(data)(f
unc)))
But to me, a compose function is much easier to read and much more
consistent with the decorator usage syntax itself.
def meta_decorator(data):
return compose(dec_register_function_for_x, dec_alter_docstring,
dec_inject_some_data(data))
The latter implementation seems much more readable and elegant. One doesn't
even need to know the decorator signature to effectively compose
meta_decorators.
I've heard it said that Python is not a functional language, but if that
were really the case, then functools would not exist. In addition to the
example described above, I've had multiple occasions where having a general
purpose function composition function would have simplified the
implementation by providing a basic functional construct. While Python isn't
primarily a functional language, it does have some functional constructs,
and this is one of the features that makes Python so versatile; one can
program functionally, procedurally, or in an object-oriented way, all within
the same language.
I admit, I may be a bit biased; my first formal programming course was
taught in Scheme.
Nevertheless, I believe functools is the ideal location for a very basic and
general capability such as composition.
I realize this patch was rejected, but I'd like to propose reviving the
patch and incorporating it into functools.
Regards,
Jason
smime.p7s
Description: S/MIME cryptographic signature
___
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] Tweaking AST lineno and col_offset
On Fri, Aug 14, 2009 at 12:16 PM, Benjamin Peterson wrote: >> I have a local patch that changes the CPython col_offset to match >> Jython's, but before I submit a patch I thought I'd ask here if there >> is support for this sort of change and if I should continue to find >> col_offset and lineno results that look fishy to me, or should I just >> change Jython's results to match (one way or another, things will be >> much easier for me to test if they match). > > Yes, please submit it. Great, the patch is here: http://bugs.python.org/issue6704 BTW - I would have added a test to test_ast.py, but above the test data it notes: EVERYTHING BELOW IS GENERATED # and I couldn't find the tool used for the generation. Does anyone know where that is? -Frank ___ 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] functools.compose to chain functions together
On 14 Aug 2009, at 20:39 , Jason R. Coombs wrote: I've heard it said that Python is not a functional language, but if that were really the case, then functools would not exist. In addition to the example described above, I've had multiple occasions where having a general purpose function composition function would have simplified the implementation by providing a basic functional construct. It's not like a basic variable-arity composition function is hard to implement though, it's basically: def compose(*funcs): return reduce(lambda f1, f2: lambda v: f1(f2(v)), funcs) it'll turn compose(a, b, c, d)(value) into a(b(c(d(value ___ 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] Tweaking AST lineno and col_offset
2009/8/14 Frank Wierzbicki : > On Fri, Aug 14, 2009 at 12:16 PM, Benjamin Peterson > wrote: > >>> I have a local patch that changes the CPython col_offset to match >>> Jython's, but before I submit a patch I thought I'd ask here if there >>> is support for this sort of change and if I should continue to find >>> col_offset and lineno results that look fishy to me, or should I just >>> change Jython's results to match (one way or another, things will be >>> much easier for me to test if they match). >> >> Yes, please submit it. > Great, the patch is here: http://bugs.python.org/issue6704 I'll take a look. > > BTW - I would have added a test to test_ast.py, but above the test > data it notes: EVERYTHING BELOW IS GENERATED # and I couldn't > find the tool used for the generation. Does anyone know where that > is? It's at the bottom of the test file. :) You can add a handwritten test above that, though. -- Regards, Benjamin ___ 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] Tweaking AST lineno and col_offset
On Fri, Aug 14, 2009 at 3:11 PM, Benjamin Peterson wrote: > 2009/8/14 Frank Wierzbicki : >> On Fri, Aug 14, 2009 at 12:16 PM, Benjamin Peterson >> wrote: >> I have a local patch that changes the CPython col_offset to match Jython's, but before I submit a patch I thought I'd ask here if there is support for this sort of change and if I should continue to find col_offset and lineno results that look fishy to me, or should I just change Jython's results to match (one way or another, things will be much easier for me to test if they match). >>> >>> Yes, please submit it. >> Great, the patch is here: http://bugs.python.org/issue6704 > > I'll take a look. > >> >> BTW - I would have added a test to test_ast.py, but above the test >> data it notes: EVERYTHING BELOW IS GENERATED # and I couldn't >> find the tool used for the generation. Does anyone know where that >> is? > > It's at the bottom of the test file. :) You can add a handwritten test > above that, though. Heh -- how did I miss that :) ? -- I'll resubmit the patch with tests. -Frank ___ 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] Tweaking AST lineno and col_offset
On Fri, Aug 14, 2009 at 3:41 PM, Frank Wierzbicki wrote: >> It's at the bottom of the test file. :) You can add a handwritten test >> above that, though. > Heh -- how did I miss that :) ? -- I'll resubmit the patch with tests. Resubmitted http://bugs.python.org/issue6704 with tests. -Frank ___ 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] functools.compose to chain functions together
It would be best to discuss this on comp.lang.python or python-ideas to get general support for the idea before trying to bring this to python-dev in hopes of changing people's minds. On Fri, Aug 14, 2009 at 11:39, Jason R. Coombs wrote: > I’d like to express additional interest in python patch 1660179, > discussed here: > > > > http://mail.python.org/pipermail/patches/2007-February/021687.html > > > > On several occasions, I’ve had the desire for something like this. I’ve > made due with lambda functions, but as was mentioned, the lambda is clumsy > and harder to read than functools.compose would be. > > > > A potentially common use-case is when a library has a multi-decorator use > case in which they want to compose a meta decorator out of one or more > individual decorators. > > > > Consider the hypothetical library. > > > > # we have three decorators we use commonly > > def dec_register_function_for_x(func): > > # do something with func > > return func > > > > def dec_alter_docstring(func): > > # do something to func.__doc__ > > return func > > > > def inject_some_data(data): > > def dec_inject_data(func): > > func.data = data # this may not be legal, > but assume it does something useful > > return func > > return dec_inject_data > > > > # we could use these decorators explicitly throughout our project > > @dec_register_function_for_x > > @dec_alter_docstring > > @dec_inject_some_data(‘foo data 1’) > > def our_func_1(params): > > pass > > > > @dec_register_function_for_x > > @dec_alter_docstring > > @dec_inject_some_data(‘foo data 2’) > > def our_func_2(params): > > pass > > > > For two functions, that’s not too onerous, but if it’s used throughout the > application, it would be nice to abstract the collection of decorators. One > could do this with lambdas. > > > > def meta_decorator(data): > > return lambda func: > dec_register_function_for_x(dec_alter_docstring(dec_inject_some_data(data)(func))) > > > > But to me, a compose function is much easier to read and much more > consistent with the decorator usage syntax itself. > > > > def meta_decorator(data): > > return compose(dec_register_function_for_x, dec_alter_docstring, > dec_inject_some_data(data)) > > > > The latter implementation seems much more readable and elegant. One > doesn’t even need to know the decorator signature to effectively compose > meta_decorators. > > > > I’ve heard it said that Python is not a functional language, but if that > were really the case, then functools would not exist. In addition to the > example described above, I’ve had multiple occasions where having a general > purpose function composition function would have simplified the > implementation by providing a basic functional construct. While Python isn’t > primarily a functional language, it does have some functional constructs, > and this is one of the features that makes Python so versatile; one can > program functionally, procedurally, or in an object-oriented way, all within > the same language. > > > > I admit, I may be a bit biased; my first formal programming course was > taught in Scheme. > > > > Nevertheless, I believe functools is the ideal location for a very basic > and general capability such as composition. > > > > I realize this patch was rejected, but I’d like to propose reviving the > patch and incorporating it into functools. > > > > Regards, > > Jason > > ___ > 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/brett%40python.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] Tweaking AST lineno and col_offset
On Fri, Aug 14, 2009 at 09:16, Benjamin Peterson wrote: > 2009/8/14 Frank Wierzbicki : > > Hi all, > > > > Off and on I have been directly comparing Jython's AST with Python's > > AST and generally working towards making them as close to identical as > > possible. There are a couple of places where I haven't "fixed" Jython > > because it looks to me like Jython has slightly better offsets. One > > example: > > > > for a,b in c: > >pass > > > > The Tuple node "a,b" ends up with a col_offset of 0 (the position of > > the "for") where Jython has the col_offset as 4 (the position of "a"). > > Jython's result is more consistent with other Tuple node col_offset > > results. > > > > I have a local patch that changes the CPython col_offset to match > > Jython's, but before I submit a patch I thought I'd ask here if there > > is support for this sort of change and if I should continue to find > > col_offset and lineno results that look fishy to me, or should I just > > change Jython's results to match (one way or another, things will be > > much easier for me to test if they match). > > Yes, please submit it. > > > > > Also, would this be a change that would be considered a backwards > > incompatibility? In other words, would patches like this be allowed > > in 2.6/3.1 or only in 2.7/3.2. > > While I don't see a problem in backporting it to maintence branches, I > would personally only apply it to the current development branches. It > doesn't seem to fix a "bug", just make a nice improvement. I like the improvement, but I disagree it should be considered for backporting as it changes semantics for something that could be considered a bug, but that feels like a stretch. -Brett ___ 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] Tweaking AST lineno and col_offset
On Fri, Aug 14, 2009 at 5:57 PM, Brett Cannon wrote: > I like the improvement, but I disagree it should be considered for > backporting as it changes semantics for something that could be considered a > bug, but that feels like a stretch. Just thought I'd ask -- I'm perfectly ok with the change being 2.7/3.2 only. -Frank ___ 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] (try-except) conditional expression similar to (if-else) conditional (PEP 308)
Jeff McAninch wrote: > I very often want something like a try-except conditional expression similar > to the if-else conditional. I think it may be done currently with the help of next function: def guard(func, *args): try: return func() except Exception, e: for exc_type, exc_func in args: if isinstance(e, exc_type): return exc_func() raise Example usage: a, b, c = 10, 20, 0 result = a + b/c # raise ZeroDivisionError result = a + guard(lambda: b/c, (TypeError, lambda: 10), (ZeroDivisionError, lambda: b/2)) May be not very concise, but it works... -- Best regards, Alexander mailto:alexander.kozlov...@gmail.com ___ 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] request for comments - standardization of python's purelib and platlib
Hi Tarek, What is needed is to remove/refactor the hardcoding of paths that currently exists within distutils and replace it with the ability to override the defaults via configuration files. (distutils.cfg?) If there's one thing that's certain for the future, its that python will go onto more platforms. Using different paths. When people are complaining about paths being hard-coded into distutils and it causing angst, I think that their complaints are valid. I can find posts going back to 2004 for windows users complaining about exactly the same thing. So it isn't a new issue. The problem applies to both linux and windows. Anyway.. do you know the code that we're talking about? David On Fri, 14 Aug 2009 10:02:03 +0200, Tarek Ziadé wrote: > On Thu, Aug 13, 2009 at 9:22 PM, Brett Cannon wrote: >> >> >> On Thu, Aug 13, 2009 at 11:23, Jan Matejek >> wrote: >>> >>> Hello, >>> >>> I'm cross-posting this to distributi...@freedesktop and python-dev, >>> because the topic is relevant to both groups and should be solved in >>> cooperation. >>> >>> The issue: >>> >>> In Python's default configuration (on linux), both purelib (location for >>> pure python modules) and platlib (location for platform-dependent binary >>> extensions) point to $prefix/lib/pythonX.Y/site-packages. >>> That is no good for two main reasons. >>> >>> One, python depends on the "lib" directory. (from distro's point of >>> view, prefix is /usr, so let's talk /usr/lib) Due to this, it's >>> impossible to install python under /usr/lib64 without heavy patching. >>> Repeated attempts to bring python developers to acknowledge and rectify >>> the situation have all failed (common argument here is "that would mean >>> redesign of distutils and huge parts of whatnot"). >> >> This is now Tarek's call, so this may or may not have changed in terms of >> what the (now) distutils maintainer thinks. >> > > I don't recall those repeated attempts , but I've been around for less > than two years. > > You are very welcome to come in the Distutils-SIG ML to discuss these > matters. > I'm moving the discussion there. > > Among the proposals you have detailed, the sharedir way seems like the > most simple/interesting > one (depending on you answer to Brett's question ) > > > Regards > Tarek ___ 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] standard library mimetypes module pathologically broken?
11 Aug 2009, Benjamin Peterson wrote: > 2009/8/11 Jacob Rus: >> I have some other questions: How does one deprecate part of a standard >> library API? How can we alert users to the deprecation? When can the >> deprecated parts be removed? > > Basically, you add a DeprecationWarning to the API. Then remove it in > the next major version. Okay, I made another patch, http://bugs.python.org/issue6626 That adds some deprecation warnings to many of the functions/methods in the module. (I think the 'strict' parameters should also be deprecated. But I'm considering actually making a new class, MimeTypesRegistry, or something, and then just making its API stay mostly compatible with MimeTypes, but extended to behave the way I think it should, and deprecating the MimeTypes class altogether, making it a subclass in the interim.) Is there any way to explicitly (i.e. in code rather than docs) deprecate string flags or dicts/lists from the module global namespace? I don't think users should be mucking with the module's singleton at all, and should be forced to make a new registry instance to customize the behavior, so they don't break each-other's code. > Then, you might garner some more reviews by putting your patch up on > Rietveld; it makes reviewing much painful. Okay, my last Rietveld link didn't get any eyeballs, but here's another try: http://codereview.appspot.com/107042 Cheers, Jacob Rus ___ 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
