Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #52491 > unrolled thread

.split() Qeustion

Back to article view | Back to comp.lang.python

Contents

  .split() Qeustion eschneider92@comcast.net - 2013-08-13 21:51 -0700
    Re: .split() Qeustion Gary Herron <gary.herron@islandtraining.com> - 2013-08-13 22:12 -0700
      Re: .split() Qeustion Alister <alister.ware@ntlworld.com> - 2013-08-14 08:30 +0000
        Re: .split() Qeustion Joshua Landau <joshua@landau.ws> - 2013-08-14 11:31 +0100
          Re: .split() Qeustion Alister <alister.ware@ntlworld.com> - 2013-08-14 13:29 +0000
          Re: .split() Qeustion Duncan Booth <duncan.booth@invalid.invalid> - 2013-08-15 09:15 +0000
            Re: .split() Qeustion wxjmfauth@gmail.com - 2013-08-15 02:46 -0700
              Re: .split() Qeustion Chris Angelico <rosuav@gmail.com> - 2013-08-15 10:54 +0100
              Re: .split() Qeustion Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-08-15 11:22 +0000
                Re: .split() Qeustion wxjmfauth@gmail.com - 2013-08-15 06:58 -0700
        Re: .split() Qeustion Peter Otten <__peter__@web.de> - 2013-08-14 13:45 +0200
        Re: .split() Qeustion Joshua Landau <joshua@landau.ws> - 2013-08-14 12:55 +0100
          Re: .split() Qeustion wxjmfauth@gmail.com - 2013-08-14 07:32 -0700
            Re: .split() Qeustion random832@fastmail.us - 2013-08-14 13:05 -0400
              Re: .split() Qeustion Steven D'Aprano <steve@pearwood.info> - 2013-08-15 07:17 +0000
            Re: .split() Qeustion Chris Angelico <rosuav@gmail.com> - 2013-08-14 18:14 +0100
              Re: .split() Qeustion wxjmfauth@gmail.com - 2013-08-15 00:46 -0700
                Re: .split() Qeustion Lele Gaifax <lele@metapensiero.it> - 2013-08-15 16:38 +0200
                Re: .split() Qeustion MRAB <python@mrabarnett.plus.com> - 2013-08-15 15:54 +0100
                Re: .split() Qeustion Lele Gaifax <lele@metapensiero.it> - 2013-08-15 17:30 +0200
                Re: .split() Qeustion Chris Angelico <rosuav@gmail.com> - 2013-08-15 16:43 +0100
                  Re: .split() Qeustion Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-08-16 04:13 +0000
                    Re: .split() Qeustion Roy Smith <roy@panix.com> - 2013-08-16 00:29 -0400
                      Re: .split() Qeustion Dave Angel <davea@davea.name> - 2013-08-16 05:27 +0000
                        Re: .split() Qeustion Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-08-17 02:38 +0000
                          Re: .split() Qeustion Chris Angelico <rosuav@gmail.com> - 2013-08-17 03:45 +0100
                      Re: .split() Qeustion Gene Heskett <gheskett@wdtv.com> - 2013-08-16 10:30 -0400
                      Re: .split() Qeustion Gene Heskett <gheskett@wdtv.com> - 2013-08-16 10:24 -0400
                        Re: .split() Qeustion Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-08-17 11:16 +1200
                    Re: .split() Qeustion Ben Finney <ben+python@benfinney.id.au> - 2013-08-16 15:59 +1000
                      Re: .split() Qeustion Roy Smith <roy@panix.com> - 2013-08-16 07:14 -0400
                        Re: .split() Qeustion wxjmfauth@gmail.com - 2013-08-16 06:14 -0700
                          Re: .split() Qeustion Roy Smith <roy@panix.com> - 2013-08-16 09:23 -0400
                            Re: .split() Qeustion wxjmfauth@gmail.com - 2013-08-17 01:09 -0700
                              Re: .split() Qeustion Roy Smith <roy@panix.com> - 2013-08-17 07:55 -0400
                              Re: .split() Qeustion Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-08-18 11:30 +1200
                                Re: .split() Qeustion wxjmfauth@gmail.com - 2013-08-18 00:17 -0700
                        Re: .split() Qeustion Grant Edwards <invalid@invalid.invalid> - 2013-08-16 13:59 +0000
                Re: .split() Qeustion Joshua Landau <joshua@landau.ws> - 2013-08-15 17:54 +0100
                Re: .split() Qeustion Chris Angelico <rosuav@gmail.com> - 2013-08-15 19:28 +0100
                  Re: .split() Qeustion Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-08-16 04:17 +0000
                Re: .split() Qeustion Joshua Landau <joshua@landau.ws> - 2013-08-15 19:40 +0100
                Re: .split() Qeustion Terry Reedy <tjreedy@udel.edu> - 2013-08-15 17:40 -0400
                  Re: .split() Qeustion Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-08-16 04:22 +0000
                Re: .split() Qeustion Dave Angel <davea@davea.name> - 2013-08-15 22:56 +0000
                  Re: .split() Qeustion Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-08-16 04:39 +0000
                    Re: .split() Qeustion Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-08-16 04:41 +0000
            Re: .split() Qeustion Tim Chase <python.list@tim.thechases.com> - 2013-08-14 12:29 -0500
            Re: .split() Qeustion Skip Montanaro <skip@pobox.com> - 2013-08-14 12:38 -0500
            Re: .split() Qeustion Chris Angelico <rosuav@gmail.com> - 2013-08-14 18:46 +0100
            Re: .split() Qeustion Terry Reedy <tjreedy@udel.edu> - 2013-08-14 15:45 -0400
    Re: .split() Qeustion Dave Angel <davea@davea.name> - 2013-08-14 05:35 +0000
    Re: .split() Qeustion eschneider92@comcast.net - 2013-08-13 22:44 -0700
    Re: .split() Qeustion Krishnan Shankar <i.am.songoku@gmail.com> - 2013-08-13 22:37 -0700
    .split() Qeustion "Alfonso Andalon Jr." <alfonsoandalon@gmail.com> - 2013-08-16 21:31 -0700

Page 1 of 3  [1] 2 3  Next page →

#52491 — .split() Qeustion

How can I use the '.split()' method (am I right in calling it a method?) without instead of writing each comma between words in the pie list in the following code? Also, is there a way to use .split instead of typing the apostrophes? Thank you.

import random
pie=['keylime', 'peach', 'apple', 'cherry', 'pecan']
print(random.choice(pie))

Eric

[toc] | [next] | [standalone]

#52492

On 08/13/2013 09:51 PM, eschneider92@comcast.net wrote:
> How can I use the '.split()' method (am I right in calling it a method?) without instead of writing each comma between words in the pie list in the following code? Also, is there a way to use .split instead of typing the apostrophes? Thank you.
>
> import random
> pie=['keylime', 'peach', 'apple', 'cherry', 'pecan']
> print(random.choice(pie))
>
> Eric

I think you are referring to this:
     pie = 'keylime peach apple cherry pecan'.split()

While it's easier to type, and does save a few characters, I think the 
original list is clearer to a reader of your program.

Gary Herron

[toc] | [prev] | [next] | [standalone]

#52502

On Tue, 13 Aug 2013 22:12:56 -0700, Gary Herron wrote:

> On 08/13/2013 09:51 PM, eschneider92@comcast.net wrote:
>> How can I use the '.split()' method (am I right in calling it a
>> method?) without instead of writing each comma between words in the pie
>> list in the following code? Also, is there a way to use .split instead
>> of typing the apostrophes? Thank you.
>>
>> import random pie=['keylime', 'peach', 'apple', 'cherry', 'pecan']
>> print(random.choice(pie))
>>
>> Eric
> 
> I think you are referring to this:
>      pie = 'keylime peach apple cherry pecan'.split()
> 
> While it's easier to type, and does save a few characters, I think the
> original list is clearer to a reader of your program.
> 
> Gary Herron

I would agree with the last statement.
Please write list definitions as lists rather than taking a short-cut to 
save a few key presses



-- 
Accuracy, n.:
	The vice of being right

[toc] | [prev] | [next] | [standalone]

#52505

On 14 August 2013 09:30, Alister <alister.ware@ntlworld.com> wrote:
> On Tue, 13 Aug 2013 22:12:56 -0700, Gary Herron wrote:
>
>> On 08/13/2013 09:51 PM, eschneider92@comcast.net wrote:
>>> How can I use the '.split()' method (am I right in calling it a
>>> method?) without instead of writing each comma between words in the pie
>>> list in the following code? Also, is there a way to use .split instead
>>> of typing the apostrophes? Thank you.
>>>
>>> import random pie=['keylime', 'peach', 'apple', 'cherry', 'pecan']
>>> print(random.choice(pie))
>>>
>>> Eric
>>
>> I think you are referring to this:
>>      pie = 'keylime peach apple cherry pecan'.split()
>>
>> While it's easier to type, and does save a few characters, I think the
>> original list is clearer to a reader of your program.
>>
>> Gary Herron
>
> I would agree with the last statement.
> Please write list definitions as lists rather than taking a short-cut to
> save a few key presses

That's true with this example, but is:

lines = [
    "Developments in high-speed rail, and high-speed",
    "transport more generally, have historically been",
    "impeded by the difficulties in managing friction",
    "and air resistance, both of which become",
    "substantial when vehicles approach high speeds.",
    "The vactrain concept eliminates these obstacles",
    "by employing magnetically levitating trains in",
    "tubes kept at a complete vacuum, allowing for",
    "heoretical speeds of thousands of miles per",
    "hour. The high cost of constructing such a system,",
    "however, and the difficulty of maintaining a",
    "vacuum over large distances, has prevented this",
    "type of system from ever being built. The",
    "Hyperloop can be viewed as a modified vactrain,",
    "employing more cost-effective solutions to the",
    "same problems the latter was designed to solve."
]

really more readable than:

lines = """\
Developments in high-speed rail, and high-speed
transport more generally, have historically been
impeded by the difficulties in managing friction
and air resistance, both of which become
substantial when vehicles approach high speeds.
The vactrain concept eliminates these obstacles
by employing magnetically levitating trains in
tubes kept at a complete vacuum, allowing for
heoretical speeds of thousands of miles per
hour. The high cost of constructing such a system,
however, and the difficulty of maintaining a
vacuum over large distances, has prevented this
type of system from ever being built. The
Hyperloop can be viewed as a modified vactrain,
employing more cost-effective solutions to the
same problems the latter was designed to solve.
"""[1:-1].split("\n")

?

Additionally,namedtuple has already set the precedence for this kind of thing.

Finally, a simple extension or a decent editor should make it trivial
to convert between the forms, so you can write the shorter way and
convert on-the-fly.

[toc] | [prev] | [next] | [standalone]

#52515

On Wed, 14 Aug 2013 11:31:01 +0100, Joshua Landau wrote:

> On 14 August 2013 09:30, Alister <alister.ware@ntlworld.com> wrote:
>> On Tue, 13 Aug 2013 22:12:56 -0700, Gary Herron wrote:
>>
>>> On 08/13/2013 09:51 PM, eschneider92@comcast.net wrote:
>>>> How can I use the '.split()' method (am I right in calling it a
>>>> method?) without instead of writing each comma between words in the
>>>> pie list in the following code? Also, is there a way to use .split
>>>> instead of typing the apostrophes? Thank you.
>>>>
>>>> import random pie=['keylime', 'peach', 'apple', 'cherry', 'pecan']
>>>> print(random.choice(pie))
>>>>
>>>> Eric
>>>
>>> I think you are referring to this:
>>>      pie = 'keylime peach apple cherry pecan'.split()
>>>
>>> While it's easier to type, and does save a few characters, I think the
>>> original list is clearer to a reader of your program.
>>>
>>> Gary Herron
>>
>> I would agree with the last statement.
>> Please write list definitions as lists rather than taking a short-cut
>> to save a few key presses
> 
> That's true with this example, but is:
> 
> lines = [
>     "Developments in high-speed rail, and high-speed", "transport more
>     generally, have historically been", "impeded by the difficulties in
>     managing friction", "and air resistance, both of which become",
>     "substantial when vehicles approach high speeds.", "The vactrain
>     concept eliminates these obstacles", "by employing magnetically
>     levitating trains in", "tubes kept at a complete vacuum, allowing
>     for", "heoretical speeds of thousands of miles per", "hour. The high
>     cost of constructing such a system,",
>     "however, and the difficulty of maintaining a", "vacuum over large
>     distances, has prevented this", "type of system from ever being
>     built. The", "Hyperloop can be viewed as a modified vactrain,",
>     "employing more cost-effective solutions to the", "same problems the
>     latter was designed to solve."
> ]
> 
> really more readable than:
> 
> lines = """\
> Developments in high-speed rail, and high-speed transport more
> generally, have historically been impeded by the difficulties in
> managing friction and air resistance, both of which become substantial
> when vehicles approach high speeds.
> The vactrain concept eliminates these obstacles by employing
> magnetically levitating trains in tubes kept at a complete vacuum,
> allowing for heoretical speeds of thousands of miles per hour. The high
> cost of constructing such a system,
> however, and the difficulty of maintaining a vacuum over large
> distances, has prevented this type of system from ever being built. The
> Hyperloop can be viewed as a modified vactrain,
> employing more cost-effective solutions to the same problems the latter
> was designed to solve.
> """[1:-1].split("\n")
> 
> ?
Yes, because I can see at the start that a list is being created & can 
skip over the data top the next line of code. I could easily miss 
the .split() at the end of the string deffinition.




-- 
"It ain't over until it's over."
-- Casey Stengel

[toc] | [prev] | [next] | [standalone]

#52541

Joshua Landau <joshua@landau.ws> wrote:

> That's true with this example, but is:
> 
> lines = [
>     "Developments in high-speed rail, and high-speed",
>     "transport more generally, have historically been",
>     "impeded by the difficulties in managing friction",
>     "and air resistance, both of which become",
>     "substantial when vehicles approach high speeds.",
>     "The vactrain concept eliminates these obstacles",
>     "by employing magnetically levitating trains in",
>     "tubes kept at a complete vacuum, allowing for",
>     "heoretical speeds of thousands of miles per",
>     "hour. The high cost of constructing such a system,",
>     "however, and the difficulty of maintaining a",
>     "vacuum over large distances, has prevented this",
>     "type of system from ever being built. The",
>     "Hyperloop can be viewed as a modified vactrain,",
>     "employing more cost-effective solutions to the",
>     "same problems the latter was designed to solve."
> ]
> 
> really more readable than:
> 
> lines = """\
> Developments in high-speed rail, and high-speed
> transport more generally, have historically been
> impeded by the difficulties in managing friction
> and air resistance, both of which become
> substantial when vehicles approach high speeds.
> The vactrain concept eliminates these obstacles
> by employing magnetically levitating trains in
> tubes kept at a complete vacuum, allowing for
> heoretical speeds of thousands of miles per
> hour. The high cost of constructing such a system,
> however, and the difficulty of maintaining a
> vacuum over large distances, has prevented this
> type of system from ever being built. The
> Hyperloop can be viewed as a modified vactrain,
> employing more cost-effective solutions to the
> same problems the latter was designed to solve.
> """[1:-1].split("\n")
> 
> ?

I suppose the question really is whether the author of the second 
example really meant to start with the word 'evelopments'?

If that was a mistake, then the first one is demonstrably less error 
prone. If it was intentional then the second one is definitely less 
readable.

Either way I think you've proved that the first way of writing it is 
more readable.

-- 
Duncan Booth

[toc] | [prev] | [next] | [standalone]

#52544

A technical ascpect of triple quoted strings is
that the "end of lines" are not respected.

>>> import zzz
>>> zzz.__doc__
'abc\ndef\n'
>>> with open('zzz.py', 'rb') as fo:
...     r = fo.read()
...     
>>> r
b'"""abc\r\ndef\r\n"""\r\n'

Now, one can argue...

jmf

[toc] | [prev] | [next] | [standalone]

#52545

On Thu, Aug 15, 2013 at 10:46 AM,  <wxjmfauth@gmail.com> wrote:
> A technical ascpect of triple quoted strings is
> that the "end of lines" are not respected.
>
>>>> import zzz
>>>> zzz.__doc__
> 'abc\ndef\n'
>>>> with open('zzz.py', 'rb') as fo:
> ...     r = fo.read()
> ...
>>>> r
> b'"""abc\r\ndef\r\n"""\r\n'
>
> Now, one can argue...

Actually, they are respected. Triple-quoted strings are parsed after
the file is read in, and newline handling is dealt with at an earlier
level, same as encodings are. You wouldn't expect that string to
retain information about the source file's encoding, and nor do you
expect it to retain the source file's newline style. A newline is
represented in the file on disk as \r\n or \n (or something else,
even), and in the string as \n. It's that simple.

ChrisA

[toc] | [prev] | [next] | [standalone]

#52547

On Thu, 15 Aug 2013 02:46:20 -0700, wxjmfauth wrote:

> A technical ascpect of triple quoted strings is that the "end of lines"
> are not respected.
> 
>>>> import zzz
>>>> zzz.__doc__
> 'abc\ndef\n'


You are misinterpreting what you are seeing. You are not reading lines of 
text from a file. You are importing a module, and they accessing its 
__doc__ attribute. The relationship between the module object and text 
from a file is tenuous, at best:

- the module's file could use \n line endings, or \r, or \r\n, or even 
something else, depending on the platform;

- the module might be a compiled .pyc file, and there are no lines of 
text to read, just byte code;

- or a .dll or .so library, again, no lines of text, just compiled code;

- or there might not even be a file, like the sys module, which is 
entirely built into the interpreter; 

- or it might not even be a module object, you can put anything into 
sys.module. It might be an instance with docstrings computed on the fly.

So you can't conclude *anything* about text files from the fact that 
module docstrings typically contain only \n rather than \r\n line 
endings. Modules are not necessarily text files, and even when they are, 
once you import them, what you get is *not text*, but Python objects.


>>>> with open('zzz.py', 'rb') as fo:
> ...     r = fo.read()
> ...
>>>> r
> b'"""abc\r\ndef\r\n"""\r\n'

And again, you are misinterpreting what you are seeing. By opening the 
file in binary mode, you are instructing Python to treat it as binary 
bytes, and return *exactly* what is stored on disk. If you opened the 
file in text mode, you would (likely, but not necessarily) get a very 
different result: the string would contain only \n line endings.

Python is not a low-level language like C. If you expect it to behave 
like a low-level language like C, you will be confused and upset.

But to prove that you are mistaken, we can do this:

py> s = """Triple-quote string\r
... containing carriage-return+newline line\r
... endings."""
py> s
'Triple-quote string\r\ncontaining carriage-return+newline line\r
\nendings.'


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#52549

--------


I perfectly knows what Python does.
I missinterpreting nothing.
I opened my example in binary mode just to show the real
endings.
It still remains the """...""" has its owns EOL and one
has to be aware of it.
No more, no less.

("""...""" and tokenize.py is funny)

jmf

[toc] | [prev] | [next] | [standalone]

#52507

Joshua Landau wrote:

> On 14 August 2013 09:30, Alister <alister.ware@ntlworld.com> wrote:
>> On Tue, 13 Aug 2013 22:12:56 -0700, Gary Herron wrote:
>>
>>> On 08/13/2013 09:51 PM, eschneider92@comcast.net wrote:
>>>> How can I use the '.split()' method (am I right in calling it a
>>>> method?) without instead of writing each comma between words in the pie
>>>> list in the following code? Also, is there a way to use .split instead
>>>> of typing the apostrophes? Thank you.
>>>>
>>>> import random pie=['keylime', 'peach', 'apple', 'cherry', 'pecan']
>>>> print(random.choice(pie))
>>>>
>>>> Eric
>>>
>>> I think you are referring to this:
>>>      pie = 'keylime peach apple cherry pecan'.split()
>>>
>>> While it's easier to type, and does save a few characters, I think the
>>> original list is clearer to a reader of your program.
>>>
>>> Gary Herron
>>
>> I would agree with the last statement.
>> Please write list definitions as lists rather than taking a short-cut to
>> save a few key presses
> 
> That's true with this example, but is:
> 
> lines = [
>     "Developments in high-speed rail, and high-speed",
...
>     "same problems the latter was designed to solve."
> ]
> 
> really more readable than:
> 
> lines = """\
> Developments in high-speed rail, and high-speed
...
> same problems the latter was designed to solve.
> """[1:-1].split("\n")
> 
> ?

It's definitely more correct -- unless you meant to strip the "D" from the 
first line ;)

I would use

lines = """\
Developments in high-speed rail, and high-speed
...
same problems the latter was designed to solve.
""".splitlines()

[toc] | [prev] | [next] | [standalone]

#52508

On 14 August 2013 12:45, Peter Otten <__peter__@web.de> wrote:
> Joshua Landau wrote:
>> On 14 August 2013 09:30, Alister <alister.ware@ntlworld.com> wrote:
>>> I would agree with the last statement.
>>> Please write list definitions as lists rather than taking a short-cut to
>>> save a few key presses
>>
>> That's true with this example, but is:
>>
>> lines = [
>>     "Developments in high-speed rail, and high-speed",
> ...
>>     "same problems the latter was designed to solve."
>> ]
>>
>> really more readable than:
>>
>> lines = """\
>> Developments in high-speed rail, and high-speed
> ...
>> same problems the latter was designed to solve.
>> """[1:-1].split("\n")
>>
>> ?
>
> It's definitely more correct -- unless you meant to strip the "D" from the
> first line ;)
>
> I would use
>
> lines = """\
> Developments in high-speed rail, and high-speed
> ...
> same problems the latter was designed to solve.
> """.splitlines()

Thanks, I didn't actually know about .splitlines()!

[toc] | [prev] | [next] | [standalone]

#52519

Le mercredi 14 août 2013 13:55:23 UTC+2, Joshua Landau a écrit :
> On 14 August 2013 12:45, Peter Otten <__peter__@web.de> wrote:
> 
> > Joshua Landau wrote:
> 
> >> On 14 August 2013 09:30, Alister <alister.ware@ntlworld.com> wrote:
> 
> >>> I would agree with the last statement.
> 
> >>> Please write list definitions as lists rather than taking a short-cut to
> 
> >>> save a few key presses
> 
> >>
> 
> >> That's true with this example, but is:
> 
> >>
> 
> >> lines = [
> 
> >>     "Developments in high-speed rail, and high-speed",
> 
> > ...
> 
> >>     "same problems the latter was designed to solve."
> 
> >> ]
> 
> >>
> 
> >> really more readable than:
> 
> >>
> 
> >> lines = """\
> 
> >> Developments in high-speed rail, and high-speed
> 
> > ...
> 
> >> same problems the latter was designed to solve.
> 
> >> """[1:-1].split("\n")
> 
> >>
> 
> >> ?
> 
> >
> 
> > It's definitely more correct -- unless you meant to strip the "D" from the
> 
> > first line ;)
> 
> >
> 
> > I would use
> 
> >
> 
> > lines = """\
> 
> > Developments in high-speed rail, and high-speed
> 
> > ...
> 
> > same problems the latter was designed to solve.
> 
> > """.splitlines()
> 
> 
> 
> Thanks, I didn't actually know about .splitlines()!

a = ['==\r**', '==\n**', '==\r\n**', '==\u0085**',
'==\u000b**', '==\u000c**', '==\u2028**', '==\u2029**']
for e in a:
    print(e.splitlines())
    
['==', '**']
['==', '**']
['==', '**']
['==', '**']
['==', '**']
['==', '**']
['==', '**']
['==', '**']


Do not confuse these NLF's (new line functions) in the Unicode
terminology, with the end of line *symbols* (pilcrow, \u2424, ...)


I'm always and still be suprised by the number of hard coded
'\n' one can find in Python code when the portable (here
win)

>>> os.linesep
'\r\n'

exists.

jmf

[toc] | [prev] | [next] | [standalone]

#52525

On Wed, Aug 14, 2013, at 10:32, wxjmfauth@gmail.com wrote:
> I'm always and still be suprised by the number of hard coded
> '\n' one can find in Python code when the portable (here
> win)
> 
> >>> os.linesep
> '\r\n'
> 
> exists.

Because high-level code isn't supposed to use the os module directly.
Text-mode streams automatically convert newlines you write to them.

[toc] | [prev] | [next] | [standalone]

#52537

On Wed, 14 Aug 2013 13:05:50 -0400, random832 wrote:

> On Wed, Aug 14, 2013, at 10:32, wxjmfauth@gmail.com wrote:
>> I'm always and still be suprised by the number of hard coded '\n' one
>> can find in Python code when the portable (here win)
>> 
>> >>> os.linesep
>> '\r\n'
>> 
>> exists.
> 
> Because high-level code isn't supposed to use the os module directly.

Say what? My brain hurts. The os module is full of lots of platform 
independent goodies. It is the right way to split and combine pathnames, 
test environment variables, manipulate file permissions, and other useful 
tasks.


> Text-mode streams automatically convert newlines you write to them.

Maybe they do, maybe they don't. It depends on whether Python is built 
with universal newline support, and what sort of text-mode stream you are 
using, and a bunch of other rules that make it a little more complicated 
than just "automatically convert".


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#52526

On Wed, Aug 14, 2013 at 6:05 PM,  <random832@fastmail.us> wrote:
> On Wed, Aug 14, 2013, at 10:32, wxjmfauth@gmail.com wrote:
>> I'm always and still be suprised by the number of hard coded
>> '\n' one can find in Python code when the portable (here
>> win)
>>
>> >>> os.linesep
>> '\r\n'
>>
>> exists.
>
> Because high-level code isn't supposed to use the os module directly.
> Text-mode streams automatically convert newlines you write to them.

I'm always, and will still be, surprised by the number of hard coded
decimal integers one can find in Python code, when the portable way to
do it is to use ctypes and figure out whether your literals should be
big-endian or little-endian, 32-bit or 64-bit, etc. Yet people
continue to just put decimal literals in their code! It can't be
portable.

ChrisA

[toc] | [prev] | [next] | [standalone]

#52540

Le mercredi 14 août 2013 19:14:59 UTC+2, Chris Angelico a écrit :
> On Wed, Aug 14, 2013 at 6:05 PM,  <random832@fastmail.us> wrote:
> 
> > On Wed, Aug 14, 2013, at 10:32, wxjmfauth@gmail.com wrote:
> 
> >> I'm always and still be suprised by the number of hard coded
> 
> >> '\n' one can find in Python code when the portable (here
> 
> >> win)
> 
> >>
> 
> >> >>> os.linesep
> 
> >> '\r\n'
> 
> >>
> 
> >> exists.
> 
> >
> 
> > Because high-level code isn't supposed to use the os module directly.
> 
> > Text-mode streams automatically convert newlines you write to them.
> 
> 
> 
> I'm always, and will still be, surprised by the number of hard coded
> 
> decimal integers one can find in Python code, when the portable way to
> 
> do it is to use ctypes and figure out whether your literals should be
> 
> big-endian or little-endian, 32-bit or 64-bit, etc. Yet people
> 
> continue to just put decimal literals in their code! It can't be
> 
> portable.
> 
> 
> 
> ChrisA

------

As a stupid scientist, I have the habbit to compare
things of the same nature with the same units.

This *string* containing one *character*

>>> sys.getsizeof('a')
26

consumes 26 *bytes*.


This *string* containing one *character*

>>> sys.getsizeof('\u2023')
40

consumes 40 *bytes*.

and the difference is

40 [bytes] - 26 [bytes] = 14 [bytes] .

—————

Python seems to consider os.linesep as a
str.

>>> isinstance(os.linesep, str)
True


—————

PS A "mole" is not a number.


jmf

[toc] | [prev] | [next] | [standalone]

#52551

wxjmfauth@gmail.com writes:

> As a stupid scientist, I have the habbit to compare
> things of the same nature with the same units.
>
> This *string* containing one *character*
>
>>>> sys.getsizeof('a')
> 26
>
> consumes 26 *bytes*.

I'm not an expert in stupid science, and I fail to see the "common"
nature of the stuff you are comparing. Strings are not characters, and
neither the latter are bytes.

Anyway, trying to apply the same stupid science, I notice a much more
amazing fact:

>>> sys.getsizeof(True)
24

Does Python really needs twentyfour bytes to store a *single* bit of
information?? Wow, since by definition a byte contains eight bits,
there's a factor of 192... what a shame!

:-)

> —————
>
> Python seems to consider os.linesep as a
> str.
>
>>>> isinstance(os.linesep, str)
> True

Yes, I bet in stupid languages that would be either a single character,
or a tuple of two or more characters, much more usable and compact.

> —————
>
> PS A "mole" is not a number.

Oh, nice to know. And OOC, what is a "mole" in your stupid science?
OTOH, WTF does that matter in current thread and with Python in general?

ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
lele@metapensiero.it  |                 -- Fortunato Depero, 1929.

[toc] | [prev] | [next] | [standalone]

#52552

On 15/08/2013 15:38, Lele Gaifax wrote:
> wxjmfauth@gmail.com writes:
>
>> As a stupid scientist, I have the habbit to compare
>> things of the same nature with the same units.
>>
>> This *string* containing one *character*
>>
>>>>> sys.getsizeof('a')
>> 26
>>
>> consumes 26 *bytes*.
>
> I'm not an expert in stupid science, and I fail to see the "common"
> nature of the stuff you are comparing. Strings are not characters, and
> neither the latter are bytes.
>
> Anyway, trying to apply the same stupid science, I notice a much more
> amazing fact:
>
>>>> sys.getsizeof(True)
> 24
>
> Does Python really needs twentyfour bytes to store a *single* bit of
> information?? Wow, since by definition a byte contains eight bits,
> there's a factor of 192... what a shame!
>
> :-)
>
>> —————
>>
>> Python seems to consider os.linesep as a
>> str.
>>
>>>>> isinstance(os.linesep, str)
>> True
>
> Yes, I bet in stupid languages that would be either a single character,
> or a tuple of two or more characters, much more usable and compact.
>
>> —————
>>
>> PS A "mole" is not a number.
>
> Oh, nice to know. And OOC, what is a "mole" in your stupid science?
> OTOH, WTF does that matter in current thread and with Python in general?
>
A "mole" is a term from chemistry:

http://en.wikipedia.org/wiki/Mole_%28unit%29

but I have no idea how it relates to Python or even to computers in
general.

[toc] | [prev] | [next] | [standalone]

#52553

MRAB <python@mrabarnett.plus.com> writes:

> On 15/08/2013 15:38, Lele Gaifax wrote:
>> wxjmfauth@gmail.com writes:
>>> PS A "mole" is not a number.
>>
>> Oh, nice to know. And OOC, what is a "mole" in your stupid science?
>> OTOH, WTF does that matter in current thread and with Python in general?
>>
> A "mole" is a term from chemistry:
>
> http://en.wikipedia.org/wiki/Mole_%28unit%29

Yes, I know that, but AFAIU, there is a closer correlation between "a
mole" and "a number" than between "a string" and "the number of bytes an
arbitrary computer [language] needs to store it". It did not come out as
funny as I meant :)

ciao, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
lele@metapensiero.it  |                 -- Fortunato Depero, 1929.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web