Re: [Python-Dev] converting the stdlib to str.format
On 05/06/2008, Steven D'Aprano <[EMAIL PROTECTED]> wrote: > Yes, I don't particularly see the advantage of writing: > > "spam %s spam" % (value,) > > over > > "spam %s spam" % value > > Why require the first version? Because the second breaks if value is a tuple: Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> value = (1,2) >>> "spam %s spam" % value Traceback (most recent call last): File "", line 1, in TypeError: not all arguments converted during string formatting Paul. ___ 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] converting the stdlib to str.format
Greg Ewing wrote: Nick Coghlan wrote: - remove support for passing a single value to a format string without wrapping it in an iterable first But won't that clobber a large number of the simple use cases that you want to keep %-formatting for? Note the part of the proposal that allows *any* iterable on the right hand side rather than the current insistence on a tuple. So the single-value use cases can be boxed easily with a list. To my mind salvaging %-formatting requires removing the ambiguity over whether or not the right hand side will be iterated over. 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] converting the stdlib to str.format
Nick Coghlan wrote: Greg Ewing wrote: Nick Coghlan wrote: - remove support for passing a single value to a format string without wrapping it in an iterable first But won't that clobber a large number of the simple use cases that you want to keep %-formatting for? Note the part of the proposal that allows *any* iterable on the right hand side rather than the current insistence on a tuple. So the single-value use cases can be boxed easily with a list. To my mind salvaging %-formatting requires removing the ambiguity over whether or not the right hand side will be iterated over. But that either needs doing for 3.0 or waiting until 4.0 right? Personally I only *occasionally* find the tuple interpolation a problem and am perfectly happy with the current % string formatting... Michael Foord Cheers, Nick. ___ 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] converting the stdlib to str.format
Raymond Hettinger wrote:
From: "Antoine" <[EMAIL PROTECTED]
For me the problem is not about ditching the % operator for an
intuitively-named method like format(). It's the format syntax which has
become much more complicated and error-prone without any clear advantage.
It's seems that way to me too. But, it may be one of those things that
you quickly get used to.
%r is about the worst case for the new syntax relative to the old - two
characters become 5. It's worth looking at what those extra characters
buy us though:
{0!r}
{}: Conversion to a bracketed format is what allows us the flexibility
to permit arbitrary format strings (such as datetime formatting), as
well as the
0: Explicit positional argument references allow arguments to be re-used
(not quite sold on this one personally - surely named arguments are even
better for that?)
!: Explicit separators (: or !) allow the option of flexible
object-controlled formatting, while still permitting the basic
formatting of str/repr/ascii if desired.
I'm really starting to wonder if supporting positional arguments to
str.format() *at all* is a mistake. Maybe we should ditch support for
positional arguments and just accept a single dictionary as the sole
parameter to format().
For dictionary formatting, str.format() is a clear winner over
str.__mod__(). For positional formatting I'm not so sure - if someone
decided to convert from %-formatting to str.format, would it be such a
burden to ask them to name their substitution variables in the process?
Silly example:
"%s occurs %s times in this format string" % (2, 2)
"{0} occurs {0} times in this format string".format(2)
"{num} occurs {num} times in this format string".format(dict(num=2))
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: Additional Discussion
Guido van Rossum wrote: Sounds good. (Maybe you want to contribute a patch to threading.py? Your implementation notes are important. It could be quite independent from PEP 371.) I created issue 3042 as an RFE to add PEP 8 compliant aliases to the threading module (including the notes about how to avoid the runtime performance hit on the old names). Jesse may want to reference that from the PEP as well. I'm not sure I'll be able to get to it for the first beta though - I'm about to go away for a few days, and plan to enjoy my computer-free holiday :) Cheers, Nick. http://bugs.python.org/issue3042 -- 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: Additional Discussion
On Thu, Jun 5, 2008 at 8:59 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: >> >> Sounds good. (Maybe you want to contribute a patch to threading.py? >> Your implementation notes are important. It could be quite independent >> from PEP 371.) > > I created issue 3042 as an RFE to add PEP 8 compliant aliases to the > threading module (including the notes about how to avoid the runtime > performance hit on the old names). Jesse may want to reference that from the > PEP as well. > > I'm not sure I'll be able to get to it for the first beta though - I'm about > to go away for a few days, and plan to enjoy my computer-free holiday :) > > Cheers, > Nick. > > http://bugs.python.org/issue3042 I'll add it to the PEP. I had to take a day to do "real work" so I can circle back to this today. The continuing outstanding question is if we should put Processing into 2.6 with the threading-like API or PEP 8 compliant names. Richard has already converted the package to PEP 8 style naming, which means I'll need to add aliases to for the original API. Ideally, both threading and processing would loose the non-PEP 8 APIs in py3k or 2.7 Before I go back to the PEP though - I'd like to see if we can reach some consensus on the API naming. My personal thought is that for many tasks, the processing module *is* a drop-in replacement (I had to do this very thing yesterday) which means that putting it in with an API which matches the current threading module's API is a Good Thing. However, the flip side of this is that no one really "likes" the threading API as-is, so putting the module into the standard library with the matching API simply adds another "broken" API. Other than the API naming - I don't think there are any other issues which need to be addressed, minus some cleanup within the PEP for consistency. -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] Mini-Pep: Simplifying the Integral ABC
Terry Reedy wrote: "Raymond Hettinger" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | From: "Guido van Rossum" <[EMAIL PROTECTED]> | > Unless more folks actually say they agree I don't want to go forward | > with this. There was quite a bit of discussion about PEP 3141 and it | > was accepted; striking this much from it with virtually no discussion | > seems wrong to me. | | Not sure how to generate more discussion. It seems self-evident | that an abc with lots of abstract methods is inherently less usable | and that bitwise operations go beyond the basic notion of "integeriness". On reading PEP3141 some months ago and again today, I thought and still do that all the methods that depend on a 2s-complement representation and implementation really belong to an implentation-defined subclass of Integral. But I am not sure of the purpose of the class and of including such concrete methods in an ABC, and so said nothing ;-). I think it definitely makes sense to separate out the number-as-sequence-of-bits operations from the main Integral ABC. This would involve moving: lshift, rshift, and, or, xor, invert (along with their reversed and in-place counterparts) Note that this leaves the Integral ABC adding only __long__, __index__ and 3-argument __pow__ over and above the Rational ABC. If 3-argument __pow__ goes (which appears likely), we're left with __long__ and __index__. However, there's still a few additional public properties and methods inherited from higher up in the numeric stack which most existing integral types are unlikely to provide: .real, .imag, .conjugate(). Unlike the methods being relocated, however, these are absolutely trivial for all non-complex numeric types. 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] converting the stdlib to str.format
On Thu, 5 Jun 2008 08:50:32 pm Paul Moore wrote: > On 05/06/2008, Steven D'Aprano <[EMAIL PROTECTED]> wrote: > > Yes, I don't particularly see the advantage of writing: > > > > "spam %s spam" % (value,) > > > > over > > > > "spam %s spam" % value > > > > Why require the first version? > > Because the second breaks if value is a tuple: That's a good reason for not using the second form if value is an arbitrary object that could be any type at all. But how often does that happen in real code? It's rare that the right hand argument can be any arbitrary type. I've looked at my code, and there's not one occasion that I've needed to write "foo %s" % (obj,) to guard against obj unexpectedly being a tuple. If obj was a tuple, it would fail long before it reached the string expression. Of course, your mileage may vary. As I see it, your argument is one for consistency: since *sometimes* you need to wrap the right-hand argument in a tuple, then we should insist in *always* wrapping it in a tuple. But of course you can do that right now: >>> n = 1 >>> "number %d" % (n,) # just in case n is a tuple 'number 1' Just don't force me to do it. -- 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
Re: [Python-Dev] PEP 371: Additional Discussion
Jesse Noller wrote: However, the flip side of this is that no one really "likes" the threading API as-is, so putting the module into the standard library with the matching API simply adds another "broken" API. Provided threading gets a PEP 8 style API in 2.6 (which it looks like it is going to), then I don't see a problem with multiprocessing only providing the new API. 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] converting the stdlib to str.format
Nick Coghlan gmail.com> writes: > > %r is about the worst case for the new syntax relative to the old - two > characters become 5. Well there are other very common "worst cases" - namely %d, %f (and probably a few less commonly used ones such as %X). > For dictionary formatting, str.format() is a clear winner over > str.__mod__(). Agreed. %(something)s is quirky - you are bound to forget the final "s" (or whatever other specifier) from time to time. Antoine. ___ 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] Mini-Pep: Simplifying the Integral ABC
On Thu, Jun 5, 2008 at 6:20 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Terry Reedy wrote: >> >> "Raymond Hettinger" <[EMAIL PROTECTED]> wrote in message >> news:[EMAIL PROTECTED] >> | From: "Guido van Rossum" <[EMAIL PROTECTED]> >> | > Unless more folks actually say they agree I don't want to go forward >> | > with this. There was quite a bit of discussion about PEP 3141 and it >> | > was accepted; striking this much from it with virtually no discussion >> | > seems wrong to me. >> | >> | Not sure how to generate more discussion. It seems self-evident >> | that an abc with lots of abstract methods is inherently less usable >> | and that bitwise operations go beyond the basic notion of >> "integeriness". >> >> On reading PEP3141 some months ago and again today, I thought and still do >> that all the methods that depend on a 2s-complement representation and >> implementation really belong to an implentation-defined subclass of >> Integral. But I am not sure of the purpose of the class and of including >> such concrete methods in an ABC, and so said nothing ;-). > > I think it definitely makes sense to separate out the > number-as-sequence-of-bits operations from the main Integral ABC. This would > involve moving: > > lshift, rshift, and, or, xor, invert (along with their reversed and in-place > counterparts) Agreed. Let's move these into a separate BinaryInteger class. > Note that this leaves the Integral ABC adding only __long__, __index__ and > 3-argument __pow__ over and above the Rational ABC. If 3-argument __pow__ > goes (which appears likely), we're left with __long__ and __index__. Let's ditch 3-arg pow, but keep __long__ (in 2.6) and __index__. Actually __long__ can go too. > However, there's still a few additional public properties and methods > inherited from higher up in the numeric stack which most existing integral > types are unlikely to provide: .real, .imag, .conjugate(). Unlike the > methods being relocated, however, these are absolutely trivial for all > non-complex numeric types. I definitely want to keep these. They're essential for people who want to use the higher-up classes in the numeric tower. I think this is settled now; Raymond can update PEP 3141 (if he refrains from editorializing) and patch numbers.py. -- --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] PEP3118, python 2.6
Hi Travis, I'm currently trying to port the pep3118 ctypes changes which are already in the py3k branch to the trunk. In py3k the tests for this stuff (in Lib/ctypes/test/test_pep3118.py) use the memoryview object which exposes attributes like .format, .shape, .strides and so on for objects implementing the new buffer interface. In Python 2.6 memoryview does not exist so the question is how to write a test that checks for the correct attributes. My idea is to implement the __array_interface__ property for ctypes instances, as described in this document http://numpy.scipy.org/array_interface.shtml. Do you think this is a good idea, or would it be better to invent another, private, mechanism for the tests? In other words: Would the __array_interface__ property (version 3) on these objects be useful for external code or would it disrupt external code? BTW: Did you have a chance to look over the test_pep3118 module in py3k, to make sure that I got things correctly (it should be pretty easy to read, imo)? -- 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] PEP 371: Additional Discussion
On Thu, Jun 5, 2008 at 9:53 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Jesse Noller wrote: >> >> However, the flip side of this is that no one really "likes" the >> threading API as-is, so putting the module into the standard library >> with the matching API simply adds another "broken" API. > > Provided threading gets a PEP 8 style API in 2.6 (which it looks like it is > going to), then I don't see a problem with multiprocessing only providing > the new API. > > Cheers, > Nick. > Fantastic. If no one has any other arguments to the contrary, I'll run with the new API naming scheme. Now I have a lot of tests and documentation to rewrite. -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] converting the stdlib to str.format
On Thu, 5 Jun 2008 10:43:20 pm Nick Coghlan wrote:
> I'm really starting to wonder if supporting positional arguments to
> str.format() *at all* is a mistake. Maybe we should ditch support for
> positional arguments and just accept a single dictionary as the sole
> parameter to format().
>
> For dictionary formatting, str.format() is a clear winner over
> str.__mod__(). For positional formatting I'm not so sure - if someone
> decided to convert from %-formatting to str.format, would it be such
> a burden to ask them to name their substitution variables in the
> process?
If positional arguments are dropped, I would expect to see a
proliferation of meaningless names used in the dicts:
"items {a} {b}".format(dict(a=spam, b=eggs))
In other words, the names will be just aliases for the position.
I would also expect a performance hit. On my computer, dict(a=spam,
b=eggs) is two times slower than {'a':spam, 'b':eggs} and nearly three
times slower than (spam, eggs). I don't imagine building a dict will
ever be faster than building a tuple. Given that format() is already
significantly slower than %, why make it slower still?
-1 on dropping positional arguments.
--
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
Re: [Python-Dev] PEP3118, python 2.6
Thomas Heller schrieb: > I'm currently trying to port the pep3118 ctypes changes which are already in > the py3k branch to the trunk. > > In py3k the tests for this stuff (in Lib/ctypes/test/test_pep3118.py) use > the memoryview object which exposes attributes like .format, .shape, .strides > and so on for objects implementing the new buffer interface. > > In Python 2.6 memoryview does not exist so the question is how to write a test > that checks for the correct attributes. My idea is to implement the > __array_interface__ property for ctypes instances, as described in this > document > http://numpy.scipy.org/array_interface.shtml. In private email Travis told me that he has no time to backport the memoryview object to Python 2.6. Maybe there is someone who could do this (Myself I have no time either for this)? 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
[Python-Dev] on Python's tests (and making them better)
Hi, This summer, I am going to be revamping Python's test suite. Major things I plan to do include - rewriting regrtest.py to be a simple test driver - implementing CPython only decorators - moving skipping data to the tests themselves (perhaps with decorators) - completing the transition to unittest/docttest - removing old test_support crud (like verify) - increasing the testing of unicode inputs and fixing bugs the appear - write new testing docs for newbie contributors - merging related tests - reorganizing the tests into separate directories Other suggestions? I also wanted to ask about the API compatibility requirements for test.test_support. IMO, we shouldn't include the testing tools as part of the stdlib. However, test_support is documented. Does anyone know any projects using test_support? -- Thanks, Benjamin Peterson "There's no place like 127.0.0.1." ___ 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] on Python's tests (and making them better)
On Thu, Jun 5, 2008 at 6:23 PM, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > Hi, > This summer, I am going to be revamping Python's test suite. Major > things I plan to do include > - rewriting regrtest.py to be a simple test driver > - implementing CPython only decorators > - moving skipping data to the tests themselves (perhaps with decorators) > - completing the transition to unittest/docttest > - removing old test_support crud (like verify) > - increasing the testing of unicode inputs and fixing bugs the appear > - write new testing docs for newbie contributors > - merging related tests > - reorganizing the tests into separate directories > > Other suggestions? Cool! I can help you with some info which tests are unlikely to pass on top of ie pypy (and *we* decided those are implementation-specific, but I might be wrong). Cheers, fijal ___ 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] Mini-Pep: Simplifying the Integral ABC
> I think I agree with Raymond on the basic principle that simple ABC's > are easier to use than simple ones. I don't think he was saying that. He was saying that simple ABC's are easier to implement to. It's not at all clear to me that simple ABC's are good in and of themselves. I think a String ABC should probably include all the methods that basestring provides, perhaps by reducing the methods that basestring provides, and moving the removed methods to the String ABC, with implementations that call the methods provided by basestring. That way, String classes could be implemented by overriding the "base" set of methods, but still inherit from String to get the other methods. But, then, isn't basestring the true simple ABC for strings? Bill ___ 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] Mini-Pep: Simplifying the Integral ABC
On Thu, Jun 05, 2008 at 09:41:44AM -0700, Bill Janssen wrote: > > I think I agree with Raymond on the basic principle that simple ABC's > > are easier to use than simple ones. > > I don't think he was saying that. He was saying that simple ABC's are > easier to implement to. Sorry; I used the wrong word. I should have said "implement to" rather than "use." I agree with you. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 signature.asc Description: Digital signature ___ 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: Additional Discussion
I've accepted your PEP. I think it still needs some clean-up and perhaps clarification of the agreement reached about API style, but there is nothing now that keeps you from implementing it! Hopefully you'll make the beta release early next week. --Guido On Thu, Jun 5, 2008 at 8:10 AM, Jesse Noller <[EMAIL PROTECTED]> wrote: > On Thu, Jun 5, 2008 at 9:53 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: >> Jesse Noller wrote: >>> >>> However, the flip side of this is that no one really "likes" the >>> threading API as-is, so putting the module into the standard library >>> with the matching API simply adds another "broken" API. >> >> Provided threading gets a PEP 8 style API in 2.6 (which it looks like it is >> going to), then I don't see a problem with multiprocessing only providing >> the new API. >> >> Cheers, >> Nick. >> > > Fantastic. If no one has any other arguments to the contrary, I'll run > with the new API naming scheme. > > Now I have a lot of tests and documentation to rewrite. > > -jesse > -- --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] PEP3118, python 2.6
On 6/5/08, Thomas Heller <[EMAIL PROTECTED]> wrote: Thomas, Iff this helps, you have attached the backport but as an extension module. Sorry, I do not have time for the full backport. But at least, I've found that the Py3K implementation works You will need to build it with 'python2.6 setup.py build' and copy 'memvwr.so' somewhere in your $PYTHONPATH, then in you 'site.py' or whatever, you can do 'import memvwr; del memvwr' . This will automaticall add the module to the __builtin__ module. Some notes: * I had to add Py_TPFLAGS_HAVE_NEWBUFFER to the type object structure. Should'nt this be already included in Py_TPFLAGS_DEFAULT ? * I have to monkey-copy two auxiliary functions 'abstrac.c' for Py3k, as ther are employed in memoryobject.c Travis, I believe you should have to review this. I'm not sure iff that is the right approach, regarding symbol visibility in shared libs in different OS's, compilers, etc.. But perhaps all is OK. Just a warning about possible problems :-). * I've not implemented the former buffer interface, I just put NULL's for the slots. Not sure if implementing the former interface is relly needed. * I've used PyString_XXX API calls. Not sure what will be the final status of the C API cleanup for Py2.6. Perhaps this should be replaced with PyBytes_ > Thomas Heller schrieb: > > > I'm currently trying to port the pep3118 ctypes changes which are already in > > the py3k branch to the trunk. > > > > In py3k the tests for this stuff (in Lib/ctypes/test/test_pep3118.py) use > > the memoryview object which exposes attributes like .format, .shape, > .strides > > and so on for objects implementing the new buffer interface. > > > > In Python 2.6 memoryview does not exist so the question is how to write a > test > > that checks for the correct attributes. My idea is to implement the > > __array_interface__ property for ctypes instances, as described in this > document > > http://numpy.scipy.org/array_interface.shtml. > > > In private email Travis told me that he has no time to backport the memoryview > object to Python 2.6. Maybe there is someone who could do this (Myself I > have > no time either for this)? > > > Thomas > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/dalcinl%40gmail.com > -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 memoryview-py2.6.tar.gz Description: GNU Zip compressed data ___ 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: Additional Discussion
I'll have a cleaned version to you by end of day, and by day, I mean by 10:00 EST :) On Thu, Jun 5, 2008 at 1:22 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > I've accepted your PEP. I think it still needs some clean-up and > perhaps clarification of the agreement reached about API style, but > there is nothing now that keeps you from implementing it! Hopefully > you'll make the beta release early next week. > > --Guido > > On Thu, Jun 5, 2008 at 8:10 AM, Jesse Noller <[EMAIL PROTECTED]> wrote: >> On Thu, Jun 5, 2008 at 9:53 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: >>> Jesse Noller wrote: However, the flip side of this is that no one really "likes" the threading API as-is, so putting the module into the standard library with the matching API simply adds another "broken" API. >>> >>> Provided threading gets a PEP 8 style API in 2.6 (which it looks like it is >>> going to), then I don't see a problem with multiprocessing only providing >>> the new API. >>> >>> Cheers, >>> Nick. >>> >> >> Fantastic. If no one has any other arguments to the contrary, I'll run >> with the new API naming scheme. >> >> Now I have a lot of tests and documentation to rewrite. >> >> -jesse >> > > > > -- > --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 371: Additional Discussion
On Thu, Jun 5, 2008 at 12:48 PM, Jesse Noller <[EMAIL PROTECTED]> wrote: > I'll have a cleaned version to you by end of day, and by day, I mean > by 10:00 EST :) Great! Please post that on the bug tracker when you're ready. -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ 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] converting the stdlib to str.format
> Agreed. %(something)s is quirky - you are bound to forget the final "s" > (or whatever other specifier) from time to time. But that gives a ValueError the first time you try it, no? Regards, Martin ___ 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] PEP3118, python 2.6
Lisandro Dalcin schrieb: > On 6/5/08, Thomas Heller <[EMAIL PROTECTED]> wrote: > Thomas, Iff this helps, you have attached the backport but as an > extension module. Sorry, I do not have time for the full backport. > But at least, I've found that the Py3K implementation works Thanks for the effort. Maybe I will look into that later. (And, if you want to make sure that your patch doesn't get lost and hopefully reviewed you should add it to the bug tracker.) In the meantime I found that I already had a _ctypes private function that can expose the needed info to Python, for ctypes pep3118 testing. Thanks again, 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] PEP 371: Additional Discussion
On Thu, Jun 5, 2008 at 2:54 PM, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > On Thu, Jun 5, 2008 at 12:48 PM, Jesse Noller <[EMAIL PROTECTED]> wrote: >> I'll have a cleaned version to you by end of day, and by day, I mean >> by 10:00 EST :) > > Great! Please post that on the bug tracker when you're ready. > > > -- > Cheers, > Benjamin Peterson > "There's no place like 127.0.0.1." > I meant a cleaned version of the PEP - I still have docs and tests to redo ___ 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: Additional Discussion
On Thu, Jun 5, 2008 at 10:06 PM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Jesse Noller wrote: >> >> I meant a cleaned version of the PEP - I still have docs and tests to redo >> > It would also be good if you could check Benjamin's patch on issue 3402 to > give threading a PEP 8 compliant API and make sure the names are the same as > the new names in multiprocessing. > > Cheers, > Nick. > > P.S. OK, now I really am going to be offline for the next few days ;) > Good idea, I'll add that to the queue - right now I'm focusing on getting the module into the build on trunk (locally) and getting all of the docs/tests updated and up to par. -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
[Python-Dev] PEP 8 vs PEP 371: Additional Discussion
Guido van Rossum wrote: > I consider multiprocessing a new API -- while it bears > a superficial resemblance with the threading API the > similarities are just that, and it should not be > constrained by mistakes in that API. The justification for including it is precisely that it is *not* a new API. For multiple processes in general, there are competing APIs, which may well be better. The advantage of this API is that (in many cases) it is a drop-in replacement for threading. If that breaks, then there really isn't any reason to include it in the stdlib yet. This doesn't prevent changing the joint API to conform with PEP 8. But why clean this module while leaving the rest of the stdlib? "Because there is a volunteer" only makes sense if changes to the other modules would also be welcomed. Is there some reason to believe that changes in the threading API are much less disruptive than changes elsewhere in the stdlib? -jJ ___ 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] converting the stdlib to str.format
Paul Moore wrote: Because the second breaks if value is a tuple: However, changing it now is going to break a huge amount of existing code that uses %-formatting, and in ways that 2to3 can't reliably fix. Keeping %-formatting but breaking a large proportion of its uses doesn't seem like a good idea to me. -- 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] converting the stdlib to str.format
Nick Coghlan wrote: %r is about the worst case for the new syntax relative to the old - two characters become 5. It's worth looking at what those extra characters buy us though: However, those benefits are only realised some of the time, and it's only in rare cases that they're all realised at once. The cost-benefit analysis needs to take the entropy into account somehow. -- 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] converting the stdlib to str.format
Nick Coghlan wrote:
Maybe we should ditch support for
positional arguments and just accept a single dictionary as the sole
parameter to format().
"{num} occurs {num} times in this format string".format(dict(num=2))
If named arguments were to become mandatory, I'd want
to be able to write that as
"...{num}...".format(num = 2)
--
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] How to specify keyword-only arguments from C?
On Thu, Jun 5, 2008 at 11:18 PM, Alexandre Vassalotti
<[EMAIL PROTECTED]> wrote:
> On Thu, Jun 5, 2008 at 10:14 PM, Mark Hammond <[EMAIL PROTECTED]> wrote:
>> Set an error if the 'arg' tuple doesn't have a length of zero?
>>
>
> Oh, that isn't a bad idea at all. I will try this. Thanks!
>
Worked flawlessly!
Just for the archives, here's how it looks like:
static int
Unpickler_init(UnpicklerObject *self, PyObject *args, PyObject *kwds)
{
static char *kwlist[] = {"file", "encoding", "errors", 0};
PyObject *file;
char *encoding = NULL;
char *errors = NULL;
if (Py_SIZE(args) != 1) {
PyErr_Format(PyExc_TypeError,
"%s takes exactly one 1 positional argument (%zd given)",
Py_TYPE(self)->tp_name, Py_SIZE(args));
return -1;
}
if (!PyArg_ParseTupleAndKeywords(args, kwds, "O|ss:Unpickler", kwlist,
&file, &encoding, &errors))
return -1;
...
Thank you, Mark, for the tip!
-- Alexandre
___
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] Mini-Pep: Simplifying the Integral ABC
[Terry Reedy] On reading PEP3141 some months ago and again today, I thought and still do that all the methods that depend on a 2s-complement representation and implementation really belong to an implentation-defined subclass of Integral. But I am not sure of the purpose of the class and of including such concrete methods in an ABC, and so said nothing ;-). [Nick Coghlan] I think it definitely makes sense to separate out the number-as-sequence-of-bits operations from the main Integral ABC. This would involve moving: lshift, rshift, and, or, xor, invert (along with their reversed and in-place counterparts) I vote for complete removal of the bit flipping methods. There's a cost to creating new ABCs that are devoid of use cases. When Terry says "I am not sure of the purpose of the class ...", I think he meant that a binary abc wasn't proposed because of its questionable utility. At some point, if you want an int type, you just use an int type. What is the purpose of having yet another layer in the "numeric tower"? Does anyone actually need an int lookalike with binary methods but cannot just inherit from int? Looking back at PEP 3119, I see there was an early decision "between standardizing more, fine-grained ABCs or fewer, course-grained ones" and that the choice was resolved in favor the few. That is how we avoided urban sprawl with the likes of "ComposableSet, MutableSet, HashableSet, MutableComposableSet, HashableComposableSet". I had thought everyone was on-board with the notion that thin abcs that capture the essence of a type are better than fat abcs that seek emulate every aspect of a single concrete type. Without agreement on that premise, simplification is a lost cause. If the group wants to go forward with a Binary subclass of Integral, then I would like to withdraw this simplification mini-pep. Better to stick with what we have now than to addcomplexity to a module that is already use case challenged. 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
