Re: [Python-3000] [Python-Dev] Issues with PEP 3101 (string formatting)

On Tue, Jun 19, 2007 at 08:20:25AM -0700, Guido van Rossum wrote: > Those are valid concerns. I'm cross-posting this to the python-3000 > list in the hope that the PEP's author and defendents can respond. I'm > sure we can work something out. Thanks to raise this. It is horrible enough that I feel

Re: [Python-3000] setup.py fails in the py3k-struni branch

Ron Adam wrote: > [...] > M Lib/tokenize.py > M Lib/test/tokenize_tests.txt > M Lib/test/output/test_tokenize > - Removed unicode literals from test results and tokenize.py. And make > it pass again. > > > M Lib/test/output/test_pep277 > - Removed unicode literals from test

Re: [Python-3000] Python 3000 Status Update (Long!)

Christian Heimes wrote: > Bill Janssen wrote: >> Though, from the standpoint of pragmatism, removing "reduce" from the >> built-in space will break code (*my* code, among others), and leaving >> it in will not affect "purity", as both "map" and "reduce" are being >> left in. So leaving it alone se

Re: [Python-3000] Python 3000 Status Update (Long!)

On 19 Jun 2007, at 21:53, Mike Klaas wrote: > ... > Stats from _any_ large python project is better than anecdotes. > Perhaps it would be better to turn to the stdlib (367289 lines)? ... >reduce(lambda a, b: (0, a[1] + b[1]), items)[1] > > (which could be written sum(x[1] for x in items) O

Re: [Python-3000] Python 3000 Status Update (Long!)

Nicko van Someren wrote: > >>> sum(['a','b','c']) > Traceback (most recent call last): > File "", line 1, in > TypeError: unsupported operand type(s) for +: 'int' and 'str' > >>> sum([["a"],[u'b'],[3]]) > Traceback (most recent call last): > File "", l

Re: [Python-3000] Issues with PEP 3101 (string formatting)

Chris McDonough wrote: > Wrt http://www.python.org/dev/peps/pep-3101/ > > PEP 3101 says Py3K should allow item and attribute access syntax > within string templating expressions but "to limit potential security > issues", access to underscore prefixed names within attribute/item > access exp

Re: [Python-3000] Python 3000 Status Update (Long!)

On 6/20/07, Nick Coghlan <[EMAIL PROTECTED]> wrote: Strings are explicitly disallowed (because Guido doesn't want a second way to spell ''.join(seq), as far as I know): More importantly, because it has positively abysmal performance, just like the reduce() solution (and, in fact, many reduce

Re: [Python-3000] On PEP 3116: new I/O base classes

Bill Janssen wrote: > Good point. Though I just grepped all my Python sources, and I never > do that, so presumably the obvious workaround of I'm using seek(0, 2) + tell() sometimes when I need to know the file size and don't want to worry about buffers. pos = fd.tell() size = None try: fd.s

Re: [Python-3000] Python 3000 Status Update (Long!)

Nick Coghlan wrote: > Because (str(x) for x in seq) is not an improvement over map(str, x) - > applying a single existing function to a sequence is a very common > operation. > > map() accepts any function (given an appropriate number of sequences), > and thus has wide applicability. > > filte

Re: [Python-3000] Issues with PEP 3101 (string formatting)

Allowing attribute and/or item access within templating expressions has historically been the domain of full-on templating languages (which invariably also have a way to do repeats, conditionals, arbitrary method calls, etc). I think it should probably stay that way because to me, at least,

Re: [Python-3000] [Python-Dev] Issues with PEP 3101 (string formatting)

On 6/19/07, Chris McDonough <[EMAIL PROTECTED]> wrote: > Given that security is a concern at all, the only truly reasonable > way to "limit security issues" is to disallow item and attribute > access completely within the string templating expression syntax. It > seems gratuituous to me to encoura

Re: [Python-3000] On PEP 3116: new I/O base classes

> > TextIOBase: this seems an odd mix of high-level and low-level. I'd > > remove "seek", "tell", "read", and "write". Remember that in Python, > > mixins actually work, so that you can provide a file object that > > combines several different I/O classes. > > Huh? All those operations you want

Re: [Python-3000] Python 3000 Status Update (Long!)

> Strings are explicitly disallowed (because Guido doesn't want a second > way to spell ''.join(seq), as far as I know): Isn't "map(str, x)" just a second way to write "[str(x) for x in y]"? This "second way" argument is another often-heard bogon. There are lots of second-way and third-way tech

Re: [Python-3000] On PEP 3116: new I/O base classes

Not bad, but if you're going that route, I think I'd get rid of the optional arguments, and just say seek_from_beginning(INCR: int) seek_from_current(INCR: int) seek_from_end(DECR: int) Bill ___ Python-3000 mailing list Python-3000@python.

Re: [Python-3000] Python 3000 Status Update (Long!)

On 20 Jun 2007, at 15:44, Nick Coghlan wrote: > Nicko van Someren wrote: >> >>> sum(['a','b','c']) >> Traceback (most recent call last): >>File "", line 1, in >> TypeError: unsupported operand type(s) for +: 'int' and 'str' >> >>> sum([["a"],[u'b'],[3]]) >> Traceb

Re: [Python-3000] How best to handle failing tests in struni?

> So, my question is how best to handle this test (and thus other tests > like it). Should it just continue to fail until someone fixes > _bsddb.c to accept Unicode keys (and thus start up a FAILING file > listing the various tests that are failing and doc which ones are > expected to fail until s

Re: [Python-3000] How best to handle failing tests in struni?

On 6/20/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > So, my question is how best to handle this test (and thus other tests > > like it). Should it just continue to fail until someone fixes > > _bsddb.c to accept Unicode keys (and thus start up a FAILING file > > listing the various tests t

Re: [Python-3000] Python 3000 Status Update (Long!)

On 6/20/07, Christian Heimes <[EMAIL PROTECTED]> wrote: > Nick Coghlan wrote: > > Because (str(x) for x in seq) is not an improvement over map(str, x) - > > applying a single existing function to a sequence is a very common > > operation. > > > > map() accepts any function (given an appropriate num

Re: [Python-3000] How best to handle failing tests in struni?

On Wed, 20 Jun 2007 10:24:55 -0700, Guido van Rossum <[EMAIL PROTECTED]> wrote: >On 6/20/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> > So, my question is how best to handle this test (and thus other tests >> > like it). Should it just continue to fail until someone fixes >> > _bsddb.c to a

[Python-3000] Summary of the differences between StringIO and cStringIO for PEP-3108

Hi, I written a short summary of the differences between the StringIO and cStringIO modules. I attached it as a patch for PEP-3108. -- Alexandre Index: pep-3108.txt === --- pep-3108.txt (revision 56050) +++ pep-3108.txt (working co

Re: [Python-3000] On PEP 3116: new I/O base classes

On 6/20/07, Bill Janssen <[EMAIL PROTECTED]> wrote: > > Ah, not everyone dealing with text is dealing with line-delimited > > text, you know... > > It's really the only difference between text and non-text. Text is a sequence of characters. Non-text is a sequence of bytes. Characters may be multi

Re: [Python-3000] On PEP 3116: new I/O base classes

On 6/20/07, Bill Janssen <[EMAIL PROTECTED]> wrote: > Not bad, but if you're going that route, I think I'd get rid of the > optional arguments, and just say > > seek_from_beginning(INCR: int) > > seek_from_current(INCR: int) > > seek_from_end(DECR: int) goto(pos) # absolute

Re: [Python-3000] On PEP 3116: new I/O base classes

Bill Janssen wrote: > Not bad, but if you're going that route, I think I'd get rid of the > optional arguments, and just say > > seek_from_beginning(INCR: int) > > seek_from_current(INCR: int) > > seek_from_end(DECR: int) I don't like it. It's too noisy and too much to type. My mini

Re: [Python-3000] How best to handle failing tests in struni?

On 6/20/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 6/20/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > > So, my question is how best to handle this test (and thus other tests > > > like it). Should it just continue to fail until someone fixes > > > _bsddb.c to accept Unicode keys (

Re: [Python-3000] Summary of the differences between StringIO and cStringIO for PEP-3108

On 6/20/07, Brett Cannon <[EMAIL PROTECTED]> wrote: > Thanks for the summary, Alexandre. Luckily your new version for the > io library does away with all of those issues for Py3K. Yes, all these issues are fixed (except the pickle thing), in my new version. -- Alexandre _

Re: [Python-3000] Python 3000 Status Update (Long!)

Alex Martelli wrote: > No, in 3.0 they'll return iterables -- you really SHOULD read Guido's > blog entry referred to at the top of this thread, > , before > discussing Python 3.0 issues. I read it. I also wasn't sure if map returns a speci

Re: [Python-3000] Python 3000 Status Update (Long!)

> It looks like an ordinary list to me. There are many things to implement yet. ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archi

Re: [Python-3000] Summary of the differences between StringIO and cStringIO for PEP-3108

On 6/20/07, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote: > Hi, > > I written a short summary of the differences between the StringIO and > cStringIO modules. I attached it as a patch for PEP-3108. Thanks for the summary, Alexandre. Luckily your new version for the io library does away with al

Re: [Python-3000] How best to handle failing tests in struni?

> And speaking of struni, when I realized that fixing _bsddb.c was not > going to be simple, I moved on to the next test (test_asynchat) and > came across a string with an 's' prefix. Just to make sure I got > everything straight, str8 produces a classic str instance (pure ASCII) > and a string wi

Re: [Python-3000] Python 3000 Status Update (Long!)

Christian Heimes schrieb: > Alex Martelli wrote: >> No, in 3.0 they'll return iterables -- you really SHOULD read Guido's >> blog entry referred to at the top of this thread, >> , before >> discussing Python 3.0 issues. > > I read it. I als

Re: [Python-3000] How best to handle failing tests in struni?

Brett Cannon wrote: > On 6/20/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> On 6/20/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: So, my question is how best to handle this test (and thus other tests like it). Should it just continue to fail until someone fixes _bsddb.c to

Re: [Python-3000] How best to handle failing tests in struni?

On 20-Jun-07, at 10:51 AM, Jean-Paul Calderone wrote: > On Wed, 20 Jun 2007 10:24:55 -0700, Guido van Rossum > <[EMAIL PROTECTED]> wrote: > > > OTOH, pragmatically, people will generally use text strings for > db keys. >> >> I'm not sure how to decide this; perhaps we need to take it public. >

Re: [Python-3000] Python 3000 Status Update (Long!)

On Wednesday 20 June 2007 18:12, Nicko van Someren wrote (about summing strings, etc.):: > The need to have an explicit 'start' value just seems wrong. It's > horribly inconsistent. Things that can be added to integers work > without initialisers but things that can be added to each other (for >

Re: [Python-3000] On PEP 3116: new I/O base classes

Daniel Stutzbach wrote: > On 6/20/07, Bill Janssen <[EMAIL PROTECTED]> wrote: > > > Ah, not everyone dealing with text is dealing with line-delimited > > > text, you know... > > > > It's really the only difference between text and non-text. > > Text is a sequence of characters. Non-text is a sequ

Re: [Python-3000] On PEP 3116: new I/O base classes

> goto(pos) # absolute > > move(incr:int) # relative to current position > > negative numbers can be interpreted naturally; for move they go > backwards, and for goto they count from the end. > > This would require either a length, or a special value (None?) for at > least one of Start

Re: [Python-3000] On PEP 3116: new I/O base classes

Christian Heimes wrote: > Bill Janssen wrote: > > Not bad, but if you're going that route, I think I'd get rid of the > > optional arguments, and just say > > > > seek_from_beginning(INCR: int) > > > > seek_from_current(INCR: int) > > > > seek_from_end(DECR: int) > > I don't like it.

Re: [Python-3000] On PEP 3116: new I/O base classes

On 6/20/07, Bill Janssen <[EMAIL PROTECTED]> wrote: > Yes, of course, Daniel, but I was speaking of the contents of files, > and files are inherently sequences of bytes. If we are talking about > some layer which interprets the contents of a file, just saying "give > me N characters" isn't enough.

Re: [Python-3000] On PEP 3116: new I/O base classes

> I'm not sure I 100% understand what you mean by "normalization policy" > (Q). Could you give an example? I was speaking of the 4 different normalization forms for Unicode, which can produce different code-point sequences. Since "strings" in Python-3000 aren't really strings, but instead are im

Re: [Python-3000] Python 3000 Status Update (Long!)

Nicko van Someren wrote: > perhaps the sum() function could be made properly polymorphic > so as to remove one more class of use cases for reduce(). That's unlikely to happen. As I remember things, sum() was deliberately restricted to numbers so as not to present an attractive nuisance as an ine

Re: [Python-3000] Python 3000 Status Update (Long!)

Christian Heimes wrote: > IIRC map and filter are a bit slower than list comprehensive But isn't that true only when the function passed is a Python function? Or are LCs faster now even for C functions? -- Greg Ewing, Computer Science Dept, +--+ University of