Re: [Python-Dev] Obtaining short file path
Hartwell Bryan wrote:
Hi,
Purpose: obtaining the system (“short”) path from a full path
Background: File dialogs (visual studio) return a full path (e.g.
f=“C:\this path has spaces\thisfilenameislongerthan8char.txt”). If
this value is provided to Python, it will not recongize this as a
file. In fact os.path.isfile(f) doesn’t return false, it crashes.
Likewise, when calling executables (from Python) with files as
arguments a short path is required. VB FileSystemObject has the
ShortPath method, while os.path and path (www.jorendorff.com) modules
do not (at least as far as my googling could determine). Why bother
creating a COM interface when you’re just going to pass as shell
run-time arguments all the values the server is better at computing?
System: Python 2.3; Windows XP
Sample Code:
import win32com.client
import time
import os,sys
import os.path
#-
def shortpath(x):
z=''
for y in x.split('\\'):
if len(y.split('.')[0])>8:
if ('.' in y):
z=z+'\\'+y.split('.')[0][:6].upper()+'~1'+'.'+y.split('.')[1]
else:
z=z+'\\'+y[:6].upper()+'~1'
else:
z=z+'\\'+y
return z[1:]
#-
xlApp = win32com.client.Dispatch("Excel.Application")
xlBook = xlApp.ActiveWorkbook
savFile = str(sys.argv[1])
rawFile = str(xlBook.Sheets("Timestamp").TextBox2)
#print os.path.isfile(savFile)
r=shortpath(rawFile)
print r
try:
print os.path.isfile(r)
except:
print 'something rude'
time.sleep(7)
Notes: This code does not account for peer paths or files that share
the first 8 characters (and file extension). I’m also aware that this
is not the normal means for submitting a “patch”, but in my job
function I don’t see myself regularly participating in python
development (and I’m probably not savvy enough) so the effort wasn’t
worth it. However I still thought others might benefit from what seems
to be (to me) a fundamental path function. Do with it, or ignore it,
as you please.
Cheers,
Bryan Hartwell
This message is intended only for the use of the intended recipients,
and it may be privileged and confidential. If you are not the intended
recipient, you are hereby notified that any review, retransmission,
conversion to hard copy, copying, circulation or other use of this
message is strictly prohibited. If you are not the intended recipient,
please notify me immediately by return e-mail, and delete this message
from your system.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/ulrich.berning%40denviso.de
Why not win32api.GetShortPathName() and win32api.GetFullPathName()?
>>> import os, win32api
>>> path = "C:\\this path has spaces\\thisfilehasmorethan8char.txt"
>>> short_path = win32api.GetShortPathName(path)
>>> short_path
'C:\\THISPA~1\\THISFI~1.TXT'
>>> os.path.isfile(short_path)
True
>>> full_path = win32api.GetLongPathName(short_path)
>>> full_path
'C:\\this path has spaces\\thisfilehasmorethan8char.txt'
>>> os.path.isfile(full_path)
True
>>> path == full_path
True
>>>
Ulli
___
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-3000] Stabilizing the C API of 2.6 and 3.0
On Thu, May 29, 2008 at 3:57 PM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > M.-A. Lemburg wrote: >> * Why should the 2.x code base turn to hacks, just because 3.x wants >> to restructure itself ? > > With the better explanation from Greg of what the checked in approach > achieves (i.e. preserving exact ABI compatibility for PyString_*, while > allowing PyBytes_* to be used at the source code level), I don't see what > has been done as being any more of a hack than the possibly more common > "#define " (which *would* break binary compatibility). > > The only things that I think would tidy it up further would be to: > - include an explanation of the approach and its effects on API and ABI > backward and forward compatibility within 2.x and between 2.x and 3.x in > stringobject.h > - expose the PyBytes_* functions to the linker in 2.6 as well as 3.0 Yes that is the only complaint I believe I really see left at this point. It is easy enough to fix. Change the current stringobject.h "#define PyBytes_Foo PyString_Foo" approach into a .c file that defines one line stub functions for all PyString_Foo() functions to call actual PyBytes_Foo() functions. I'd even go so far as to put the one line alternate name stubs in the Objects/bytesobject.c and .h file right next to the PyBytes_Foo() method definitions so that its clear from reading a single file that they are the same thing. The performance implications of this are minor all things considered (a single absolute jmp given a good compiler) and regardless of what we do should only apply to extension modules, not the core. If we do the above in trunk will this thread end? I'm personally not really clear on why we need PyBytes_Foo to show up in the -binary- ABI in 2.6. The #define's are enough for me but I'm happy to make this compromise. No 2.x books, documentation or literature will be invalidated by the changes regardless. -gps ___ 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] Iterable String Redux (aka String ABC)
Georg Brandl wrote: Greg Ewing schrieb: A better solution to that might be to have UserString inherit from basestring. But with that argument you could throw out the whole ABC machinery, just let all lists inherit from list, all dicts from dict, etc. Well, I'm skeptical about the whole ABC thing in the first place -- it all seems very unpythonic to me. But another way of thinking about it is that we already have an ABC of sorts for strings, and it's called basestring. It might be better to enhance that with whatever's considered missing than introducing another one. -- 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] [Python-3000] Stabilizing the C API of 2.6 and 3.0
On 2008-05-30 00:57, Nick Coghlan wrote:
M.-A. Lemburg wrote:
* Why can't we have both PyString *and* PyBytes exposed in 2.x,
with one redirecting to the other ?
We do have that - the PyString_* names still work perfectly fine in 2.x.
They just won't be used in the Python core codebase anymore - everything
in the Python core will use either PyBytes_* or PyUnicode_* regardless
of which branch (2.x or 3.x) you're working on. I think that's a good
thing for ease of maintenance in the future, even if it takes people a
while to get their heads around it right now.
Sorry, I probably wasn't clear enough:
Why can't we have both PyString *and* PyBytes exposed as C
APIs (ie. visible in code and in the linker) in 2.x, with one redirecting
to the other ?
* Why should the 2.x code base turn to hacks, just because 3.x wants
to restructure itself ?
With the better explanation from Greg of what the checked in approach
achieves (i.e. preserving exact ABI compatibility for PyString_*, while
allowing PyBytes_* to be used at the source code level), I don't see
what has been done as being any more of a hack than the possibly more
common "#define " (which *would* break binary
compatibility).
The only things that I think would tidy it up further would be to:
- include an explanation of the approach and its effects on API and ABI
backward and forward compatibility within 2.x and between 2.x and 3.x in
stringobject.h
- expose the PyBytes_* functions to the linker in 2.6 as well as 3.0
Which is what I was suggesting all along; sorry if I wasn't
clear enough on that.
The standard approach is that you provide #define redirects from the
old APIs to the new ones (which are then picked up by the compiler)
*and* add function wrappers to the same affect (to make linkers,
dynamic load APIs such ctypes and debuggers happy).
Example from pythonrun.h|c:
---
/* Use macros for a bunch of old variants */
#define PyRun_String(str, s, g, l) PyRun_StringFlags(str, s, g, l, NULL)
/* Deprecated C API functions still provided for binary compatiblity */
#undef PyRun_String
PyAPI_FUNC(PyObject *)
PyRun_String(const char *str, int s, PyObject *g, PyObject *l)
{
return PyRun_StringFlags(str, s, g, l, NULL);
}
I still believe that we should *not* make "easy of merging" the
primary motivation for backporting changes in 3.x to 2.x. Software
design should not be guided by restrictions in the tool chain,
if not absolutely necessary.
The main argument for a backport needs to be general usefulness
to the 2.x users, IMHO... just like any other feature that
makes it into 2.x.
If merging is difficult then this needs to be addressed, but
there are more options to that than always going back to the
original 2.x trunk code. I've given a few suggestions on how
this could be approached in other emails on this thread.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, May 30 2008)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
2008-07-07: EuroPython 2008, Vilnius, Lithuania37 days to go
Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free !
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
___
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] optimization required: .format() is much slower than %
Simon Cross wrote: It struct me as odd that this one case shows such a big difference while the others show less of one. I believe the %-formatting code has some optimisations in place where it realises it can just increment the reference count of the passed in string and return that, rather than having to build a new string object. As for why you didn't see any differences in a couple of your tests: the .format() call wasn't actually substituting anything. Unfortunately, the reasons why .format() doesn't complain about extra arguments never made it into the PEP. They can be found here: http://mail.python.org/pipermail/python-dev/2006-May/065062.html 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] PEP 371 Discussion (pyProcessing Module)
On Fri, May 30, 2008 at 2:19 AM, Farshid Lashkari <[EMAIL PROTECTED]> wrote: > On Wed, May 28, 2008 at 10:03 AM, Jesse Noller <[EMAIL PROTECTED]> wrote: >> I would like to renew the discussion now that "there is a PEP" to see >> if there are any outstanding things people would like to get resolved. >> I chose to continue to push it for 2.6 / 3.0 inclusion due to feedback >> both here and elsewhere that people would rather see this in sooner in >> some form, rather than later (i.e.: 2.7/3.1). > > I'm not sure if this is a big issue, but I just tested the module with > an application that embeds Python and it doesn't work properly. > Instead of spawning worker threads using python.exe, it attempts to > use the application. Does the processing module allow specifying the > exe to use for spawning worker threads? I would definitely like to see > this included in the next release, and having support for embedded > Python interpreters would be a big plus. > > -Farshid > Let's take this off-list Farshid - but I would like to know more about your application (I'm not up to speed with embedding python in other applications) so I can either add it to the PEP or discuss how best to address this within the module itself. -jesse ___ 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 371 Discussion (pyProcessing Module)
Jesse Noller schrieb: > On Fri, May 30, 2008 at 2:19 AM, Farshid Lashkari <[EMAIL PROTECTED]> wrote: >> On Wed, May 28, 2008 at 10:03 AM, Jesse Noller <[EMAIL PROTECTED]> wrote: >>> I would like to renew the discussion now that "there is a PEP" to see >>> if there are any outstanding things people would like to get resolved. >>> I chose to continue to push it for 2.6 / 3.0 inclusion due to feedback >>> both here and elsewhere that people would rather see this in sooner in >>> some form, rather than later (i.e.: 2.7/3.1). >> >> I'm not sure if this is a big issue, but I just tested the module with >> an application that embeds Python and it doesn't work properly. >> Instead of spawning worker threads using python.exe, it attempts to >> use the application. Does the processing module allow specifying the >> exe to use for spawning worker threads? I would definitely like to see >> this included in the next release, and having support for embedded >> Python interpreters would be a big plus. >> >> -Farshid >> > > Let's take this off-list Farshid - but I would like to know more about > your application (I'm not up to speed with embedding python in other > applications) so I can either add it to the PEP or discuss how best to > address this within the module itself. This may be an issue for py2exe users as well. Please keep me informed (or is there a pyprocessing mailing list where this is discussed?). Thanks, 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] Iterable String Redux (aka String ABC)
Greg Ewing canterbury.ac.nz> writes: > Well, I'm skeptical about the whole ABC thing in the > first place -- it all seems very unpythonic to me. I think it's very pythonic and the very best solution to interfaces *and* duck typing. Not only does it extend duck-typing in a very, very cool way but also does it provide a very cool way to get custom sets or lists going with few extra work. Subclassing builtins was always very painful in the past and many used the User* objects which however often broke because some code did something like isinstance(x, (tuple, list)). Of course one could argue that instance checking is the root of all evil but there are situations where you have to do instance checking. And ABCs are the perfect solution for that as they combine duck-typing and instance checking. In my oppinion ABCs are the best feature of 2.6 and 3.0. > But another way of thinking about it is that we > already have an ABC of sorts for strings, and it's > called basestring. It might be better to enhance > that with whatever's considered missing than > introducing another one. basestring is not subclassable for example. Also it requires subclassing which ABCs do not. Regards, Armin ___ 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] Iterable String Redux (aka StringABC)
Raymond Hettinger wrote: "Jim Jewett" It isn't really stringiness that matters, it is that you have to terminate even though you still have an iterable container. Well said. Guido had at least a start in Searchable, back when ABC were still in the sandbox: Have to disagree here. An object cannot know in general whether a flattener wants to split it or not. That is an application dependent decision. A better answer is be able to tell the flattener what should be considered atomic in a given circumstance. Raymond A while back (a couple of years I think), we had a discussion on python-list about flatten in which I posted the following version of a flatten function. It turned out to be nearly twice as fast as any other version. def flatten(L): """ Flatten a list in place. """ i = 0 while i < len(L): while type(L[i]) is list: L[i:i+1] = L[i] i += 1 return L For this to work the object to be flattened needs to be both mutable and list like. At the moment I can't think of any reason I would want to flatten anything that was not list like. To make it a bit more flexible it could be changed just a bit. def flatten(L): """ Flatten a list in place. """ objtype = type(L) i = 0 while i < len(L): while type(L[i]) is objtype: L[i:i+1] = L[i] i += 1 return L Generally, I don't think you would want to flatten dissimilar objects. Cheers, Ron ___ 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] Summary of Python tracker Issues
ACTIVITY SUMMARY (05/23/08 - 05/30/08) 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. 1889 open (+35) / 12944 closed (+25) / 14833 total (+60) Open issues with patches: 566 Average duration of open issues: 706 days. Median duration of open issues: 1437 days. Open Issues Breakdown open 1866 (+35) pending23 ( +0) Issues Created Or Reopened (63) ___ Cant open python gui using VISTA 05/28/08 CLOSED http://bugs.python.org/issue1948reopened amaury.forgeotdarc Remove commands for PEP 3108 05/26/08 CLOSED http://bugs.python.org/issue2872reopened brett.cannon patch ElementTree parsing bus error (but only from mod_python) 05/23/08 http://bugs.python.org/issue2951created kathyvs List comprehensions are leaking variables05/23/08 CLOSED http://bugs.python.org/issue2952created cartman _zip_directory_cache untested and undocumented 05/23/08 http://bugs.python.org/issue2953created fijal [PATCH] Make bisect module functions accept an optional comparis 05/23/08 CLOSED http://bugs.python.org/issue2954created llucax patch Python 2.5 Documentation error in Tutorial section 8.3 05/24/08 CLOSED http://bugs.python.org/issue2955created dcw303 2to3 should have a way to disable some fixers05/24/08 http://bugs.python.org/issue2956created bhy patch recursion limit exceeded when importing .pyc module 05/24/08 CLOSED http://bugs.python.org/issue2957created bhy update Lib/test/README 05/24/08 http://bugs.python.org/issue2958created benjamin.peterson easy calling GzipFile close() more than once causes exception 05/24/08 CLOSED http://bugs.python.org/issue2959created mmagin patch bsddb/test/test_replication.py bus error, segfault, assertion er 05/25/08 http://bugs.python.org/issue2960created gregory.p.smith Two error messages inconsistent 05/25/08 CLOSED http://bugs.python.org/issue2961created chester Goodbye, 'global' statement! 05/25/08 CLOSED http://bugs.python.org/issue2962created chester Method cache is broken in Py305/25/08 CLOSED http://bugs.python.org/issue2963created scoder patch instancemethod_descr_get() lacks an INCREF 05/25/08 CLOSED http://bugs.python.org/issue2964created scoder patch Update interface of weakref dictionaries 05/25/08 http://bugs.python.org/issue2965created georg.brandl patch pydoc doesnt show 'from module import identifier' in the docs05/25/08 http://bugs.python.org/issue2966created peter.puk [PATCH] Rename Tkinter to tkinter in test_tcl05/25/08 CLOSED http://bugs.python.org/issue2967created cartman patch Test_imports takes a long time to run
Re: [Python-Dev] Iterable String Redux (aka String ABC)
Armin Ronacher wrote: Greg Ewing canterbury.ac.nz> writes: Well, I'm skeptical about the whole ABC thing in the first place -- it all seems very unpythonic to me. I think it's very pythonic and the very best solution to interfaces *and* duck typing. Not only does it extend duck-typing in a very, very cool way but also does it provide a very cool way to get custom sets or lists going with few extra work. Subclassing builtins was always very painful in the past and many used the User* objects which however often broke because some code did something like isinstance(x, (tuple, list)). Of course one could argue that instance checking is the root of all evil but there are situations where you have to do instance checking. And ABCs are the perfect solution for that as they combine duck-typing and instance checking. In my oppinion ABCs are the best feature of 2.6 and 3.0. But another way of thinking about it is that we already have an ABC of sorts for strings, and it's called basestring. It might be better to enhance that with whatever's considered missing than introducing another one. basestring is not subclassable for example. Also it requires subclassing which ABCs do not. I would be strongly +1 on a string ABC. Currently (to my knowledge) there is no way of using duck typing for built-in APIs that expect a string. How do I pass in an object to 'open' for example that isn't actually a string or subclass? >>> class X(object): ... def __unicode__(self): ... return 'fish' ... __str__ = __repr__ = __unicode__ ... >>> x = X() >>> open(x) Traceback (most recent call last): File "", line 1, in TypeError: coercing to Unicode: need string or buffer, X found >>> unicode(x) u'fish' Michael Foord Regards, Armin ___ Python-Dev mailing list [email protected] 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.theotherdelia.co.uk/ http://www.voidspace.org.uk/ http://www.ironpython.info/ http://www.resolverhacks.net/ ___ 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 371 Discussion (pyProcessing Module)
Thomas Heller wrote: Jesse Noller schrieb: On Fri, May 30, 2008 at 2:19 AM, Farshid Lashkari <[EMAIL PROTECTED]> wrote: On Wed, May 28, 2008 at 10:03 AM, Jesse Noller <[EMAIL PROTECTED]> wrote: I would like to renew the discussion now that "there is a PEP" to see if there are any outstanding things people would like to get resolved. I chose to continue to push it for 2.6 / 3.0 inclusion due to feedback both here and elsewhere that people would rather see this in sooner in some form, rather than later (i.e.: 2.7/3.1). I'm not sure if this is a big issue, but I just tested the module with an application that embeds Python and it doesn't work properly. Instead of spawning worker threads using python.exe, it attempts to use the application. Does the processing module allow specifying the exe to use for spawning worker threads? I would definitely like to see this included in the next release, and having support for embedded Python interpreters would be a big plus. -Farshid Let's take this off-list Farshid - but I would like to know more about your application (I'm not up to speed with embedding python in other applications) so I can either add it to the PEP or discuss how best to address this within the module itself. This may be an issue for py2exe users as well. Please keep me informed (or is there a pyprocessing mailing list where this is discussed?). py2exe is explicitly supported (via the freezeSupport() call). That may work for the embedded case as well, or it may be something that can be addressed by modifying sys.executable. 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] Iterable String Redux (aka String ABC)
Michael Foord wrote: I would be strongly +1 on a string ABC. Currently (to my knowledge) there is no way of using duck typing for built-in APIs that expect a string. How do I pass in an object to 'open' for example that isn't actually a string or subclass? Implement the character buffer API, which you can't actually do from Python code :P 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] PEP 371 Discussion (pyProcessing Module)
On Fri, May 30, 2008 at 9:29 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > py2exe is explicitly supported (via the freezeSupport() call). That may work > for the embedded case as well, or it may be something that can be addressed > by modifying sys.executable. Thanks for the tip Nick. Adding the following line before using the module works for me: sys.executable = os.path.join(sys.exec_prefix,'pythonw.exe') I'm not sure if there will be any side affects to modifying sys.executable though. Should this be the official way of supporting embedded interpreters or should there be a multiprocessing.setExecutable() method? -Farshid ___ 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-3000] Iterable String Redux (aka StringABC)
Perhaps drawing a distinction between containers (or maybe "collections"?), and non-container iterables is appropriate? I would define containers as objects that can be iterated over multiple times and for which iteration does not instantiate new objects. By this definition generators would not be considered containers (but views would), and for practicality it may be worth also having an ABC for containers-and-generators (no idea what to name it). This would result in the following hierarchy: iterables - strings, bytes, etc. - containers-and-generators - - containers - - - tuple, list, set, dict views, etc. - - generators I don't think there needs to be different operations defined for the different ABCs. They're all just iterables with different iteration semantics. Jamie On Tue, May 27, 2008 at 3:54 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > "Jim Jewett" > >> It isn't really stringiness that matters, it is that you have to >> terminate even though you still have an iterable container. >> > > Well said. > > > Guido had at least a start in Searchable, back when ABC >> were still in the sandbox: >> > > Have to disagree here. An object cannot know in general > whether a flattener wants to split it or not. That is an application > dependent decision. A better answer is be able to tell the > flattener what should be considered atomic in a given circumstance. > > > Raymond > > ___ > Python-3000 mailing list > [EMAIL PROTECTED] > http://mail.python.org/mailman/listinfo/python-3000 > Unsubscribe: > http://mail.python.org/mailman/options/python-3000/jgennis%40gmail.com > ___ 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] A thought on generic functions
Greg Ewing wrote: Paul Moore wrote: I'd rather see a solution which addressed the wider visitor use case (I think I just sprained my back bending over backwards to avoid mentioning generic functions :-)) Speaking of generic functions, while thinking about the recent discussion on proxy objects, it occurred to me that this is something you can do with an OO system that you can't do so easily with a generic function system. If the operations being proxied were generic functions rather than methods, you'd have to override them all individually instead of having a central point to catch them all. It depends on your dispatch rules. Say the implementation orders the candidates lexically (like default CLOS). This is equivalent to choosing as first candidates the set of functions with the most specific first argument. Resolution for a generic function call and generic method call are semantically the same, so there's no reason not to have the latter, and proxying by __getattr__ tricks becomes doable again. Neil ___ 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] optimization required: .format() is much slower than %
Eric Smith wrote:
Eric Smith wrote:
Nick Coghlan wrote:
Secondly, the string % operator appears to have an explicit
optimisation for the 'just return str(self)' case. This optimisation
is missing from the new string format method.
I'll see if I can optimize this case.
3.0, from svn:
$ ./python.exe -m timeit "'some text with {0}'.format('nothing')"
10 loops, best of 3: 3.14 usec per loop
3.0, with PyUnicode_ExactCheck, skipping __format__ lookup:
$ ./python.exe -m timeit "'some text with {0}'.format('nothing')"
10 loops, best of 3: 2.32 usec per loop
I could probably improve this some more, by skipping the creation of the
object used to describe the format_spec.
Compare with:
$ ./python.exe -m timeit "'some text with %s' % 'nothing'"
100 loops, best of 3: 1.37 usec per loop
r63826 has an optimization when formatting types that are exactly
unicode, long, or float (not subclasses). Unfortunately it's only for
3.0. For 2.6 it's messier. I'm still pondering what to do with that.
I'll get to it sometime, but maybe after the beta.
There's much more that can be done, but I'd like to profile it before I
just start guessing.
___
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] Iterable String Redux (aka String ABC)
On Sat, 31 May 2008 12:48:41 am Armin Ronacher wrote: > Greg Ewing canterbury.ac.nz> writes: > > Well, I'm skeptical about the whole ABC thing in the > > first place -- it all seems very unpythonic to me. > > I think it's very pythonic and the very best solution to interfaces > *and* duck typing. Not only does it extend duck-typing in a very, > very cool way I'm with Greg on this one: despite the assertions made in the PEP, I don't see how ABC can fail to be anything but anti-duck-typing. How does it extend duck-typing? Can you give an example? > but also does it provide a very cool way to get custom > sets or lists going with few extra work. Subclassing builtins was > always very painful in the past "Always" very painful? class ListWithClear(list): def clear(self): self[:] = self.__class__() Not so very painful to me. Maybe I just have more pain-tolerance than some people. > and many used the User* objects which > however often broke because some code did something like > isinstance(x, (tuple, list)). Of course one could argue that > instance checking is the root of all evil Perhaps not the root of *all* evil but it is certainly the root of much evil, and the treatment of delegation-based classes like UserString as second-class objects is a good example of why isinstance checking should be avoided as much as possible. -- Steven ___ 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
