Greg Ewing wrote:
> Anders J. Munch wrote:
> > any file that supports seeking to the end will also support
> > reporting the file size. Thus
> > f.seek(f.length)
> > should suffice,
>
> Although the micro-optimisation circuit in my
> brain complains that it will take 2 system
> calls when it co
>> IMHO, it would be better to label the module "scripting" rather than
>> "beginnerlib" (and why append "lib" at the end of module names
>> anyway? :-)).
>> It might even contain stuff such as encoding guessing.
>>
> from scripting import raw_input, autotextfile
>
> I'm not so keen on 'scripti
Brett Cannon wrote:
> On 9/11/06, *Michael Chermside* <[EMAIL PROTECTED]
> Personally, I think input() should never have existed and must go
> no matter what.
>
>
> Agreed. Teach the folks eval() quick if you want something like that.
The world would probably be a happier place if you
Nick Coghlan wrote:
> We could always rename raw_input() to input(). Just a thought. . .
D'oh. Guido already said he doesn't like that idea :)
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
We could always rename raw_input() to input(). Just a thought. . .
D'oh. Guido already said he doesn't like that idea :)
FWIW, I think it is a good idea. If there is a little 2.x vs 3.0
confusion, so be it. The use of input() function is already somewhat
rare (both
"Anders J. Munch" <[EMAIL PROTECTED]> wrote:
>
> Greg Ewing wrote:
> > Anders J. Munch wrote:
> > > any file that supports seeking to the end will also support
> > > reporting the file size. Thus
> > > f.seek(f.length)
> > > should suffice,
> >
> > Although the micro-optimisation circuit in m
On 9/12/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
> We could always rename raw_input() to input(). Just a thought. . .
>
> D'oh. Guido already said he doesn't like that idea :)
>
>
>
> FWIW, I think it is a good idea. If there is a little 2.x vs 3.0
> confusion, so be it. The use of
> How about calling it 'ask'?
>
> >>> s = ask( "How are you today?" )
> --> Fine
> >>> s
> "Fine"
>
> And as far as the name of a library goes how about "quickstart"? Other
> possibilities are: quickstudy, kickstart, simplestart, etc.
>
> "With the Python quickstart module, programming is as easy
Toby Donaldson wrote:
>> How about calling it 'ask'?
>>
>> >>> s = ask( "How are you today?" )
>> --> Fine
>> >>> s
>> "Fine"
>>
>> And as far as the name of a library goes how about "quickstart"? Other
>> possibilities are: quickstudy, kickstart, simplestart, etc.
>>
>> "With the Python quicksta
On 9/12/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
> We could always rename raw_input() to input(). Just a thought. . .
>
> D'oh. Guido already said he doesn't like that idea :)
>
> FWIW, I think it is a good idea. If there is a little 2.x vs 3.0
> confusion, so be it. The use of inpu
Raymond Hettinger wrote:
>
>>> We could always rename raw_input() to input(). Just a thought. . .
>>>
>>
>> D'oh. Guido already said he doesn't like that idea :)
>>
>>
>
> FWIW, I think it is a good idea. If there is a little 2.x vs 3.0
> confusion, so be it. The use of input() functi
Ron Adam wrote:
>Maybe "input" can be depreciated in 2.x with a messages to use
>eval(raw_input())
>instead. That would limit some of the confusion.
>
>
>
Let me take this opportunity to articulate a principle that I hope this
group will adopt, "Thou shalt not muck-up Py2.x in the name of P
> > The idea of a standard edu library though is a GREAT one. That would
> > provide a standard place for things like raw_input() (with a better
> > name) as well as lots of other "helper functions" useful to beginners
> > and/or students -- and all it would cost is a single line of boilerplate
> >
On 9/12/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Ron Adam wrote:
> >Maybe "input" can be depreciated in 2.x with a messages to use
> >eval(raw_input())
> >instead. That would limit some of the confusion.
>
> Let me take this opportunity to articulate a principle that I hope this
> group
Paul Prescod schrieb:
> I haven't created locale-relevant content in a generic text editor in a
> very, very long time.
You are an atypical user, then. I use plain text files all the time, and
I know other people do as well.
Regards,
Martin
___
Python-3
Fredrik Lundh schrieb:
> just noticed that PEP 3100 says that PyString_AsEncodedString and
> PyString_AsDecodedString is to be removed, but it doesn't mention
> any other PyString (or PyUnicode) functions.
>
> how large changes can we make here, really ?
All API that refers to the internal repres
Paul Prescod schrieb:
> I think that the gist of it is that Unicode will be "just one character
> set" supported by Ruby. This idea has been kicked around for Python
> before but you quickly run into questions about how you compare
> character strings from multiple character sets, to say nothing of
Fredrik Lundh schrieb:
> today's Python supports "locale aware" 8-bit strings; e.g.
>
> >>> import locale
> >>> "åäö".isalpha()
> False
> >>> locale.setlocale(locale.LC_ALL, "sv_SE")
> 'sv_SE'
> >>> "åäö".isalpha()
> True
>
> to what extent should this be supported by
Brian Quinlan schrieb:
> As a user, I don't have any expectations regarding non-ASCII text files.
>
> I'm using a US-English version of Windows XP (very common) and I haven't
> changed the default encoding (very common). Python claims that my system
> encoding is CP436 (from sys.stdin/stdout.enc
tomer filiba schrieb:
> # read 3 UTF8 *characters*
> f.read(3)
>
> # this will seek by AT LEAST 7 *bytes*, until resynched
> f.substream.seekby(7)
>
> # we can resume reading of UTF8 *characters*
> f.read(3)
>
> heck, i even like this idea :)
Notice that resyncing is a really tricky operation,
David Hopwood schrieb:
> Cp436 is almost certainly *not* the encoding set by the OS; Python
> has got it wrong.
Just to repeat myself: Python is *not* wrong, the terminal *indeed*
uses CP 436.
> If Brian is using an English-language variant of
> Windows XP and has not changed the defaults, the sy
Fredrik Lundh schrieb:
>> The best you could do would be to return some kind
>> of opaque object from tell() that could be passed
>> back to seek().
>
> that's how seek/tell works on text files in today's Python, of course.
> if you're writing portable code, you can only seek to the beginning or
On 9/12/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> I can assure you> that most of the documents that I work with are not in CP436 - they are> a combination of ASCII, ISO8859-1, and UTF-8. I would also guess that> this is true of many Windows XP (US-English) users. So, for me and users
> lik
23 matches
Mail list logo
