Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #47884 > unrolled thread
| Started by | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| First post | 2013-06-13 01:55 +0000 |
| Last post | 2013-06-14 10:05 +0100 |
| Articles | 20 on this page of 115 — 33 participants |
Back to article view | Back to comp.lang.python
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: A certainl part of an if() structure never gets executed. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-13 01:55 +0000
Re: A certainl part of an if() structure never gets executed. Chris Angelico <rosuav@gmail.com> - 2013-06-13 12:03 +1000
Re: A certainl part of an if() structure never gets executed. Kushal Kumaran <kushal.kumaran+python@gmail.com> - 2013-06-13 10:05 +0530
Re: A certainl part of an if() structure never gets executed. Chris Angelico <rosuav@gmail.com> - 2013-06-13 14:39 +1000
Re: A certainl part of an if() structure never gets executed. Νικόλαος Κούρας <support@superhost.gr> - 2013-06-13 08:36 +0300
Re: A certainl part of an if() structure never gets executed. Νικόλαος Κούρας <support@superhost.gr> - 2013-06-13 10:11 +0300
Re: A certainl part of an if() structure never gets executed. Sibylle Koczian <nulla.epistola@web.de> - 2013-06-13 14:22 +0200
Re: A certainl part of an if() structure never gets executed. Νικόλαος Κούρας <support@superhost.gr> - 2013-06-13 17:26 +0300
Re: A certainl part of an if() structure never gets executed. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-14 01:14 +0000
Re: A certainl part of an if() structure never gets executed. Nick the Gr33k <support@superhost.gr> - 2013-06-14 11:03 +0300
Re: A certainl part of an if() structure never gets executed. Chris Angelico <rosuav@gmail.com> - 2013-06-14 18:23 +1000
Re: A certainl part of an if() structure never gets executed. "R. Michael Weylandt" <michael.weylandt@gmail.com> - 2013-06-14 09:24 +0100
Re: A certainl part of an if() structure never gets executed. Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2013-06-14 11:28 +0300
Re: A certainl part of an if() structure never gets executed. Nick the Gr33k <support@superhost.gr> - 2013-06-14 11:41 +0300
Re: A certainl part of an if() structure never gets executed. Chris Angelico <rosuav@gmail.com> - 2013-06-14 18:50 +1000
Re: A certainl part of an if() structure never gets executed. Fábio Santos <fabiosantosart@gmail.com> - 2013-06-14 10:03 +0100
Re: A certainl part of an if() structure never gets executed. Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2013-06-14 12:21 +0300
Re: A certainl part of an if() structure never gets executed. Nick the Gr33k <support@superhost.gr> - 2013-06-14 12:44 +0300
Re: A certainl part of an if() structure never gets executed. Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2013-06-14 15:40 +0300
Re: A certainl part of an if() structure never gets executed. Nick the Gr33k <support@superhost.gr> - 2013-06-14 16:07 +0300
Re: A certainl part of an if() structure never gets executed. Zero Piraeus <schesis@gmail.com> - 2013-06-14 09:48 -0400
Re: A certainl part of an if() structure never gets executed. rusi <rustompmody@gmail.com> - 2013-06-14 07:05 -0700
Re: A certainl part of an if() structure never gets executed. Nick the Gr33k <support@superhost.gr> - 2013-06-14 17:08 +0300
Re: A certainl part of an if() structure never gets executed. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-14 16:31 +0000
Re: A certainl part of an if() structure never gets executed. Nick the Gr33k <support@superhost.gr> - 2013-06-14 19:56 +0300
Re: A certainl part of an if() structure never gets executed. Chris Angelico <rosuav@gmail.com> - 2013-06-15 03:18 +1000
Re: A certainl part of an if() structure never gets executed. Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2013-06-14 21:17 +0300
Re: A certainl part of an if() structure never gets executed. Larry Hudson <orgnut@yahoo.com> - 2013-06-14 22:27 -0700
Re: A certainl part of an if() structure never gets executed. Nick the Gr33k <support@superhost.gr> - 2013-06-15 11:39 +0300
Re: A certainl part of an if() structure never gets executed. Lele Gaifax <lele@metapensiero.it> - 2013-06-15 11:54 +0200
Re: A certainl part of an if() structure never gets executed. Nick the Gr33k <support@superhost.gr> - 2013-06-15 16:07 +0300
Re: A certainl part of an if() structure never gets executed. Michael Torrie <torriem@gmail.com> - 2013-06-15 09:53 -0600
Re: A certainl part of an if() structure never gets executed. Nick the Gr33k <support@superhost.gr> - 2013-06-15 19:18 +0300
Re: A certainl part of an if() structure never gets executed. Michael Torrie <torriem@gmail.com> - 2013-06-15 11:45 -0600
Re: A certainl part of an if() structure never gets executed. Denis McMahon <denismfmcmahon@gmail.com> - 2013-06-16 06:32 +0000
Re: A certainl part of an if() structure never gets executed. Nick the Gr33k <support@superhost.gr> - 2013-06-16 11:07 +0300
Re: A certainl part of an if() structure never gets executed. Denis McMahon <denismfmcmahon@gmail.com> - 2013-06-16 09:22 +0000
Re: A certainl part of an if() structure never gets executed. Nick the Gr33k <support@superhost.gr> - 2013-06-16 12:59 +0300
Re: A certainl part of an if() structure never gets executed. "R. Michael Weylandt" <michael.weylandt@gmail.com> - 2013-06-16 11:42 +0100
Re: A certainl part of an if() structure never gets executed. Ferrous Cranus <support@superhost.gr> - 2013-06-16 14:06 +0300
Re: A certainl part of an if() structure never gets executed. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-06-16 12:26 +0100
Re: A certainl part of an if() structure never gets executed. YBM <ybmess@nooos.fr.invalid> - 2013-06-16 14:00 +0200
Re: A certainl part of an if() structure never gets executed. "R. Michael Weylandt" <michael.weylandt@gmail.com> - 2013-06-16 13:04 +0100
Re: A certainl part of an if() structure never gets executed. Ferrous Cranus <support@superhost.gr> - 2013-06-16 16:38 +0300
Re: A certainl part of an if() structure never gets executed. "R. Michael Weylandt" <michael.weylandt@gmail.com> - 2013-06-16 19:50 +0100
Re: A certainl part of an if() structure never gets executed. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-06-16 11:52 +0100
Re: A certainl part of an if() structure never gets executed. Denis McMahon <denismfmcmahon@gmail.com> - 2013-06-16 10:51 +0000
Compiling vs interpreting [was Re: A certainl part of an if() structure never gets executed.] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-16 12:07 +0000
Re: Compiling vs interpreting [was Re: A certainl part of an if() structure never gets executed.] Mark Janssen <dreamingforward@gmail.com> - 2013-06-16 12:31 -0700
Re: Compiling vs interpreting [was Re: A certainl part of an if() structure never gets executed.] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-16 20:02 +0000
Re: Compiling vs interpreting [was Re: A certainl part of an if() structure never gets executed.] Chris Angelico <rosuav@gmail.com> - 2013-06-17 08:26 +1000
Re: Compiling vs interpreting [was Re: A certainl part of an if() structure never gets executed.] Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-06-16 23:13 -0400
Re: A certainl part of an if() structure never gets executed. Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2013-06-16 14:13 +0300
Re: A certainl part of an if() structure never gets executed. Ferrous Cranus <support@superhost.gr> - 2013-06-16 16:47 +0300
Re: A certainl part of an if() structure never gets executed. "R. Michael Weylandt" <michael.weylandt@gmail.com> - 2013-06-16 19:53 +0100
Re: A certainl part of an if() structure never gets executed. Νίκος <support@superhost.gr> - 2013-06-17 08:17 +0300
Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-17 06:51 +0000
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Simpleton <support@superhost.gr> - 2013-06-17 14:34 +0300
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Michael Torrie <torriem@gmail.com> - 2013-06-17 05:58 -0600
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Simpleton <support@superhost.gr> - 2013-06-17 18:50 +0300
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Larry Hudson <orgnut@yahoo.com> - 2013-06-17 23:39 -0700
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-18 07:24 +0000
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Νίκος <support@superhost.gr> - 2013-06-18 11:49 +0300
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-18 09:05 +0000
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Νίκος <support@superhost.gr> - 2013-06-18 12:51 +0300
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Chris Angelico <rosuav@gmail.com> - 2013-06-18 20:22 +1000
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Michael Torrie <torriem@gmail.com> - 2013-06-19 23:16 -0600
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-20 05:48 +0000
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Michael Torrie <torriem@gmail.com> - 2013-06-20 00:01 -0600
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] 88888 Dihedral <dihedral88888@gmail.com> - 2013-06-26 01:18 -0700
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Michael Torrie <torriem@gmail.com> - 2013-06-19 23:44 -0600
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Roel Schroeven <roel@roelschroeven.net> - 2013-06-20 19:19 +0200
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Terry Reedy <tjreedy@udel.edu> - 2013-06-17 10:22 -0400
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Simpleton <support@superhost.gr> - 2013-06-17 18:55 +0300
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Joel Goldstick <joel.goldstick@gmail.com> - 2013-06-17 12:26 -0400
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Benjamin Kaplan <benjamin.kaplan@case.edu> - 2013-06-17 09:23 -0700
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Νίκος <support@superhost.gr> - 2013-06-17 20:17 +0300
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Terry Reedy <tjreedy@udel.edu> - 2013-06-17 18:16 -0400
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-17 23:09 +0000
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Νίκος <support@superhost.gr> - 2013-06-18 02:26 +0300
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-18 00:41 +0000
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Dave Angel <davea@davea.name> - 2013-06-17 21:06 -0400
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-18 02:42 +0000
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Dave Angel <davea@davea.name> - 2013-06-18 00:12 -0400
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-18 06:04 +0000
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-18 02:38 +0000
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-18 02:46 +0000
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-06-17 21:34 -0400
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Marcin Szamotulski <mszamot@gmail.com> - 2013-06-18 04:22 +0100
Re: A certainl part of an if() structure never gets executed. Michael Weylandt <michael.weylandt@gmail.com> - 2013-06-17 07:56 +0100
Re: A certainl part of an if() structure never gets executed. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-16 12:50 +0000
OT: C vs Python terminology (was: A certainl part of an if() structure never gets executed) Andreas Perstinger <andipersti@gmail.com> - 2013-06-16 13:22 +0200
Re: OT: C vs Python terminology Dave Angel <davea@davea.name> - 2013-06-16 08:55 -0400
Re: OT: C vs Python terminology Andreas Perstinger <andipersti@gmail.com> - 2013-06-16 17:02 +0200
Re: OT: C vs Python terminology Dave Angel <davea@davea.name> - 2013-06-16 21:58 -0400
Re: A certainl part of an if() structure never gets executed. "R. Michael Weylandt" <michael.weylandt@gmail.com> - 2013-06-14 09:28 +0100
Re: A certainl part of an if() structure never gets executed. Fábio Santos <fabiosantosart@gmail.com> - 2013-06-14 09:35 +0100
Re: A certainl part of an if() structure never gets executed. Nick the Gr33k <support@superhost.gr> - 2013-06-14 11:44 +0300
Re: A certainl part of an if() structure never gets executed. Chris Angelico <rosuav@gmail.com> - 2013-06-14 18:57 +1000
Re: A certainl part of an if() structure never gets executed. Nick the Gr33k <support@superhost.gr> - 2013-06-14 12:00 +0300
Re: A certainl part of an if() structure never gets executed. Chris Angelico <rosuav@gmail.com> - 2013-06-14 19:12 +1000
Re: A certainl part of an if() structure never gets executed. Nick the Gr33k <support@superhost.gr> - 2013-06-14 12:47 +0300
Re: A certainl part of an if() structure never gets executed. Tim Roberts <timr@probo.com> - 2013-06-15 18:55 -0700
Re: A certainl part of an if() structure never gets executed. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-16 05:09 +0000
Re: A certainl part of an if() structure never gets executed. Nick the Gr33k <support@superhost.gr> - 2013-06-16 11:20 +0300
Re: A certainl part of an if() structure never gets executed. Tim Roberts <timr@probo.com> - 2013-06-18 22:08 -0700
Re: A certainl part of an if() structure never gets executed. Dave Angel <davea@davea.name> - 2013-06-19 01:42 -0400
Re: A certainl part of an if() structure never gets executed. Chris Angelico <rosuav@gmail.com> - 2013-06-19 17:14 +1000
Re: A certainl part of an if() structure never gets executed. Νίκος <support@superhost.gr> - 2013-06-19 10:49 +0300
Re: A certainl part of an if() structure never gets executed. Dave Angel <davea@davea.name> - 2013-06-19 04:06 -0400
Re: A certainl part of an if() structure never gets executed. Chris Angelico <rosuav@gmail.com> - 2013-06-19 18:21 +1000
Re: A certainl part of an if() structure never gets executed. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-19 08:55 +0000
Re: A certainl part of an if() structure never gets executed. Chris Angelico <rosuav@gmail.com> - 2013-06-19 19:14 +1000
Re: A certainl part of an if() structure never gets executed. Grant Edwards <invalid@invalid.invalid> - 2013-06-14 14:38 +0000
Re: A certainl part of an if() structure never gets executed. Fábio Santos <fabiosantosart@gmail.com> - 2013-06-14 10:05 +0100
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-06-18 00:41 +0000 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <51bfacd0$0$29872$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #48577 |
On Tue, 18 Jun 2013 02:26:39 +0300, Νίκος wrote:
> Στις 18/6/2013 2:09 πμ, ο/η Steven D'Aprano έγραψε:
>> {"a": "Hello world"}
>>
>> Do you see a memory location there? There is no memory location. There
>> is the name, "a", and the object it is associated with, "Hello world".
>> Either the dict, or the string, may move around memory if the
>> underlying memory manager allows it. Obviously any object in Python
>> must be *somewhere* in memory at any specific moment, but that is
>> irrelevant to understanding Python code. It is no more relevant than
>> saying that a dict {'a': 5} is just made up of bits.
>
> Okey, the easy part was to understand how humans in high level need to
> understand namespaces and assignment (which is not copying but instead
> referencing another name to the same object).
>
> But i would like to know, what happens internally within the python
> compiler, because obviously memory is involved.
Depends which Python compiler.
CPython, IronPython, PyPy, Jython, Nuitka, Cython, ... ? They all operate
differently on the inside. Only the high-level Python code has to be the
same.
Jython works according to the JRE, the Java Runtime Environment. There is
masses of information about that on the Internet, google for it.
IronPython works according to the .Net runtime environment. Again, google
for it.
PyPy is a VERY complex but powerful JIT compiler. You can read about it
on the PyPy blog. Start here: http://morepypy.blogspot.com/
There's not a lot of documentation on how CPython works internally. You
have to read the C source code. You will need to understand about garbage
collectors, memory management, the difference between the stack and the
heap, etc. It's a big area to study. Don't expect anyone to spend the
days or weeks it will take to explain the whole thing.
> The way some info(i.e. a Unicode string) is saved into the hdd , is the
> same way its being saved into the memory too? Same way exactly?
No. Unicode strings can be stored on disk in any encoding you like.
Python stores string in memory as objects, which might look something
like this:
[Type=str, size=42, data=...]
only more complicated. And subject to change -- anything you learn that
holds for Python 3.3 might not apply for 3.2 or 3.4.
In Python 3.2 and older, the data will be either UTF-4 or UTF-8, selected
when the Python compiler itself is compiled. In Python 3.3, the data will
be stored in either Latin-1, UTF-4, or UTF-8, depending on the contents
of the string.
> While you said to me to forget about memory locations, and that's indeed
> made things easy to follow i still keep wondering, how Python internally
> keeping tracks of 'x' and 'y' names as well as their referenced objects
> (i.e. number 6).
Good question, but I don't have a good answer. It has to do with the
Python's memory manager, and the garbage collector. I don't know how they
work.
> After all the way i understand memory is as a series of bits like:
>
> 0100010100011110101000010101010010001001010010011100001101001010010
>
> So from the above binary form:
>
> what is 'x', what is 'y', how's 'x' and 'y' differ from the actually
> memory locations that are bound too, and of course what is the actual
> value.
>
> Its 3 things for me to consider, even in Python id internal level
> detail. I want to understand this.
>
> names, memory addresses, memory address's actual values
Start here:
https://duckduckgo.com/html/?q=how%20computers%20work
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Dave Angel <davea@davea.name> |
|---|---|
| Date | 2013-06-17 21:06 -0400 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <mailman.3500.1371517631.3114.python-list@python.org> |
| In reply to | #48581 |
On 06/17/2013 08:41 PM, Steven D'Aprano wrote: > > <SNIP> > > In Python 3.2 and older, the data will be either UTF-4 or UTF-8, selected > when the Python compiler itself is compiled. I think that was a typo. Do you perhaps UCS-2 or UCS-4 > In Python 3.3, the data will > be stored in either Latin-1, UTF-4, or UTF-8, depending on the contents > of the string. > > -- DaveA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-06-18 02:42 +0000 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <51bfc931$0$29872$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #48583 |
On Mon, 17 Jun 2013 21:06:57 -0400, Dave Angel wrote: > On 06/17/2013 08:41 PM, Steven D'Aprano wrote: >> >> <SNIP> >> >> In Python 3.2 and older, the data will be either UTF-4 or UTF-8, >> selected when the Python compiler itself is compiled. > > I think that was a typo. Do you perhaps UCS-2 or UCS-4 Yes, that would be better. UCS-2 is identical to UTF-16, except it doesn't support non-BMP characters and therefore doesn't have surrogate pairs. UCS-4 is functionally equivalent to UTF-16, as far as I can tell. (I'm not really sure what the difference is.) -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Dave Angel <davea@davea.name> |
|---|---|
| Date | 2013-06-18 00:12 -0400 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <mailman.3506.1371528775.3114.python-list@python.org> |
| In reply to | #48590 |
On 06/17/2013 10:42 PM, Steven D'Aprano wrote: > On Mon, 17 Jun 2013 21:06:57 -0400, Dave Angel wrote: > >> On 06/17/2013 08:41 PM, Steven D'Aprano wrote: >>> >>> <SNIP> >>> >>> In Python 3.2 and older, the data will be either UTF-4 or UTF-8, >>> selected when the Python compiler itself is compiled. >> >> I think that was a typo. Do you perhaps UCS-2 or UCS-4 > > Yes, that would be better. > > UCS-2 is identical to UTF-16, except it doesn't support non-BMP > characters and therefore doesn't have surrogate pairs. > > UCS-4 is functionally equivalent to UTF-16, Perhaps you mean UTF-32 ? as far as I can tell. (I'm > not really sure what the difference is.) > Now you've got me curious, by bringing up surrogate pairs. Do you know whether a narrow build (say 3.2) really works as UTF16, so when you encode a surrogate pair (4 bytes) to UTF-8, it encodes a single Unicode character into a single UTF-8 sequence (prob. 4 bytes long) ? -- DaveA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-06-18 06:04 +0000 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <51bff874$0$29872$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #48593 |
On Tue, 18 Jun 2013 00:12:34 -0400, Dave Angel wrote:
> On 06/17/2013 10:42 PM, Steven D'Aprano wrote:
>> On Mon, 17 Jun 2013 21:06:57 -0400, Dave Angel wrote:
>>
>>> On 06/17/2013 08:41 PM, Steven D'Aprano wrote:
>>>>
>>>> <SNIP>
>>>>
>>>> In Python 3.2 and older, the data will be either UTF-4 or UTF-8,
>>>> selected when the Python compiler itself is compiled.
>>>
>>> I think that was a typo. Do you perhaps UCS-2 or UCS-4
>>
>> Yes, that would be better.
>>
>> UCS-2 is identical to UTF-16, except it doesn't support non-BMP
>> characters and therefore doesn't have surrogate pairs.
>>
>> UCS-4 is functionally equivalent to UTF-16,
>
> Perhaps you mean UTF-32 ?
Yes, sorry for the repeated confusion.
>> as far as I can tell. (I'm
>> not really sure what the difference is.)
>>
>>
> Now you've got me curious, by bringing up surrogate pairs. Do you know
> whether a narrow build (say 3.2) really works as UTF16, so when you
> encode a surrogate pair (4 bytes) to UTF-8, it encodes a single Unicode
> character into a single UTF-8 sequence (prob. 4 bytes long) ?
In a Python narrow build, the internal storage of strings is equivalent
to UTF-16: all characters in the Basic Multilingual Plane require two
bytes:
py> sys.maxunicode
65535
py> sys.getsizeof('π') - sys.getsizeof('')
2
Outside of the BMP, characters are treated as a pair of surrogates:
py> c = chr(0x10F000) # one character...
py> len(c) # ...stored as a pair of surrogates
2
Encoding and decoding works fine:
py> c.encode('utf-8').decode('utf-8') == c
True
py> c.encode('utf-8')
b'\xf4\x8f\x80\x80'
The problem with surrogates is that it is possible to accidentally
separate the pair, which leads to broken, invalid text:
py> c[0].encode('utf-8')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'utf-8' codec can't encode character '\udbfc' in
position 0: surrogates not allowed
(The error message is a little misleading; surrogates are allowed, but
only if they make up a valid pair.)
Python's handling of UTF-16 is, as far as I know, correct. What isn't
correct is that the high-level Python string methods assume that two
bytes == one character, which can lead to surrogates being separated,
which gives you junk text. Wide builds don't have this problem, because
every character == four bytes, and neither does Python 3.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-06-18 02:38 +0000 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <51bfc81c$0$29872$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #48581 |
On Tue, 18 Jun 2013 00:41:53 +0000, Steven D'Aprano wrote: > In Python 3.2 and older, the data will be either UTF-4 or UTF-8, > selected when the Python compiler itself is compiled. In Python 3.3, the > data will be stored in either Latin-1, UTF-4, or UTF-8, depending on the > contents of the string. UTF-4? UTF-8? Whatever crack I was smoking, it obviously was *bad* crack. That should be UTF-8 or UTF-16. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-06-18 02:46 +0000 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <51bfca09$0$29872$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #48589 |
On Tue, 18 Jun 2013 02:38:20 +0000, Steven D'Aprano wrote: > On Tue, 18 Jun 2013 00:41:53 +0000, Steven D'Aprano wrote: > >> In Python 3.2 and older, the data will be either UTF-4 or UTF-8, >> selected when the Python compiler itself is compiled. In Python 3.3, >> the data will be stored in either Latin-1, UTF-4, or UTF-8, depending >> on the contents of the string. > > UTF-4? UTF-8? > > Whatever crack I was smoking, it obviously was *bad* crack. > > That should be UTF-8 or UTF-16. Good lord, that crack is worse than I thought. UTF-16 and UTF-32. Bloody hell. I am ashamed. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2013-06-17 21:34 -0400 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <mailman.3502.1371519290.3114.python-list@python.org> |
| In reply to | #48577 |
On Tue, 18 Jun 2013 02:26:39 +0300, ????? <support@superhost.gr> declaimed
the following:
>
>But i would like to know, what happens internally within the python
>compiler, because obviously memory is involved.
>
Fine... Download the Python SOURCE code, and read it...
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
[toc] | [prev] | [next] | [standalone]
| From | Marcin Szamotulski <mszamot@gmail.com> |
|---|---|
| Date | 2013-06-18 04:22 +0100 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <mailman.3505.1371525742.3114.python-list@python.org> |
| In reply to | #48577 |
> While you said to me to forget about memory locations, and that's indeed > made things easy to follow i still keep wondering, how Python internally > keeping tracks of 'x' and 'y' names as well as their referenced objects > (i.e. number 6). There is an excellent blog post about CPython internals: http://tech.blog.aknin.name/category/my-projects/pythons-innards/ but it might be difficult to follow if you cannot at least read C. It explains how python virtual machine works internally, how the opcodes are evaluated, how the three scopes globals, locals and builins find its place (and how names are bind). As far as I understand names are keys in the scope dictionaries, which are exposed in the python level as locals(), globals() and the builtin's. This is how Python tracks names and their values. To be more precise, when you do: >>> a = 1 >>> def f(): ... b=2 in the first line 'a' is added to the globals() dictionary with value 1, and in the third line 'b' with value 2 is added to the local dictionary of f. It is also all explained in the python docs, and it reflects how python is implemented (at least CPython). > > After all the way i understand memory is as a series of bits like: > > 0100010100011110101000010101010010001001010010011100001101001010010 > > So from the above binary form: > > what is 'x', what is 'y', how's 'x' and 'y' differ from the actually > memory locations that are bound too, and of course what is the actual value. 'x' and 'y' are just strings which are written somewhere in the computer's memory. > > Its 3 things for me to consider, even in Python id internal level > detail. I want to understand this. > > names, memory addresses, memory address's actual values Names and values are not connected through their memory addresses but because they live in a higher structure, name is a key and value is a value of a dictionary (which is also represented in some way at the C level, namely by PyDictObject ... but for this you need to first learn C, but please read and understand the Python docs - there is already a lot there for you ... Best regards, Marcin
[toc] | [prev] | [next] | [standalone]
| From | Michael Weylandt <michael.weylandt@gmail.com> |
|---|---|
| Date | 2013-06-17 07:56 +0100 |
| Message-ID | <mailman.3476.1371458380.3114.python-list@python.org> |
| In reply to | #48493 |
[Multipart message — attachments visible in raw view] — view raw
On Jun 17, 2013, at 6:17, Νίκος <support@superhost.gr> wrote: > On 16/6/2013 9:53 μμ, R. Michael Weylandt wrote: >> On Sun, Jun 16, 2013 at 2:47 PM, Ferrous Cranus <support@superhost.gr> wrote: >>> On 16/6/2013 2:13 μμ, Jussi Piitulainen wrote: >>>> >>>> If, instead of the above, you have >>>> >>>> a = 6 >>>> b = a >>>> b = 5 >>>> >>>> you will find that b == 5 and a == 6. So b is not the same as a. Else >>>> one would have changed when the other changed. I would say that a and >>>> b are different variables. They had the same value, briefly. >>> >>> >>> If they were different variables then they would have different memory >>> addresses and they would act like two different objects. >>> >>> But... both a and b are for a fact mappings for the same memory address as >>> seen form the following command. >>> >>>>>> id(a) == id(b) >>> True >>> >>> They are like the same object with 2 different names. >> >> This will depend on when the test is run: >> >> a = 6 >> b = a >> a is b # True >> >> b = 5 >> a is b # False >> >> The latter is false because the binding of "b" to the int 6 was broken >> in order to bind b to the int 5. > > Very surprising. > a and b was *references* to the same memory address, it was like a memory address having 2 names to be addresses as. > > b = a name we use to address some memory location, do we agree on that? > > So, b = 6, must have changed the stored value of its mapped memory location, but given you example it seems its changing the mapping of b to some other memory address. > > I don't follow its act of course. I'm having trouble understanding your grammar in the above, but please re-read my note on the dual behavior of `=` here: http://mail.python.org/pipermail/python-list/2013-June/649990.html Michael
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-06-16 12:50 +0000 |
| Message-ID | <51bdb47b$0$29966$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #48424 |
On Sun, 16 Jun 2013 09:22:20 +0000, Denis McMahon wrote: >>> Python: >>> >>> b = 6 >>> a = b >>> >>> In Python, this first puts the value 6 in in a memory location and >>> points "b" at that memory location, then makes "a" point to the same >>> memory location as "b" points to. That may be true in some sense for CPython, the reference implementation, but it is not a promise of the language. For example, in PyPy objects are free to move around in memory, so you cannot meaningfully speak of "putting 6 in a memory location" or having a variable "point to the same memory location". The language promise is that the two names, "a" and "b", both refer to the same object. In the same way that, depending on who you ask, "Barack Obama", "Mr President", and "Dad" are three names referring to the same person. Anything more than that depends on the implementation. [...] > For example, in Python > > a = 6 > b = a > c = 6 > > a and b point to one memory location that contains the value 6 c points > to a different memory location that contains the value 6 Well, maybe it does, maybe it doesn't. This is one area where the language does not specify the underlying behaviour. Because ints are unchangeable, immutable objects, the implementation is free to cache and reuse them if it wants. CPython caches small integers, but not floats. Other implementations may cache fewer, or more, immutable objects. One thing which no Python implementation can do though is re-use *mutable* objects. [...] > These are really C terms, not Python terms. Stop thinking that C is > behaving like Python. This is certainly true! -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Andreas Perstinger <andipersti@gmail.com> |
|---|---|
| Date | 2013-06-16 13:22 +0200 |
| Subject | OT: C vs Python terminology (was: A certainl part of an if() structure never gets executed) |
| Message-ID | <mailman.3438.1371381735.3114.python-list@python.org> |
| In reply to | #48416 |
On 16.06.2013 08:32, Denis McMahon wrote: > C: > > int a, b; > b = 6; > a = b; > > In C, this places the numeric value 6 into the memory location identified > by the variable "b", so far so good. > then copies the value from the location pointed to by "b" into the > location pointed to by "a". Wrong. Neither "a" nor "b" are pointers, thus they don't point to a memory location. This part should be written as "then copies the value at the location identified by "b" to the location identified by "a". > b is a pointer to a memory location containing the value 6 > a is a pointer to another memory location also containing the value 6 Again, neither "a" nor "b" are pointers. "b" is the name of a memory location containing the integer value 6. "a" is the name of another memory location containing the integer value 6. > Python: > > b = 6 > a = b > > In Python, this first puts the value 6 in in a memory location and points > "b" at that memory location, then makes "a" point to the same memory > location as "b" points to. > > b is a pointer to a memory location containing the value 6 > a is a pointer to the same memory location I wouldn't use the term "pointer" in context with Python. Using the terms from the language reference I would write that as "In Python, this first creates an integer object with value 6 and then binds the name "b" to it. Then it binds the name "a" to the same object. Thus both "a" and "b" reference the same object, i.e. they are different names for the same object." Bye, Andreas
[toc] | [prev] | [next] | [standalone]
| From | Dave Angel <davea@davea.name> |
|---|---|
| Date | 2013-06-16 08:55 -0400 |
| Subject | Re: OT: C vs Python terminology |
| Message-ID | <mailman.3441.1371387333.3114.python-list@python.org> |
| In reply to | #48416 |
On 06/16/2013 07:22 AM, Andreas Perstinger wrote: > On 16.06.2013 08:32, Denis McMahon wrote: >> C: >> >> int a, b; >> b = 6; >> a = b; >> >> In C, this places the numeric value 6 into the memory location identified >> by the variable "b", > > so far so good. > >> then copies the value from the location pointed to by "b" into the >> location pointed to by "a". > > Wrong. Neither "a" nor "b" are pointers, thus they don't point to a > memory location. > This part should be written as > "then copies the value at the location identified by "b" to the location > identified by "a". But it doesn't. It binds b to the same object to which a is currently bound. > >> b is a pointer to a memory location containing the value 6 > > a is a pointer to another memory location also containing the value 6 > > Again, neither "a" nor "b" are pointers. > "b" is the name of a memory location containing the integer value 6. > "a" is the name of another memory location containing the integer value 6. > Not even close. If you don't like the terms "bound" or "points", the perhaps you'd be happy with "b" is the name that currently knows how to find an int object containing 6. That object has no name, and never will. And it can exist for a long time with no names directly bound to it. >> Python: >> >> b = 6 >> a = b >> >> In Python, this first puts the value 6 in in a memory location and points >> "b" at that memory location, then makes "a" point to the same memory >> location as "b" points to. >> >> b is a pointer to a memory location containing the value 6 >> a is a pointer to the same memory location > > I wouldn't use the term "pointer" in context with Python. Using the > terms from the language reference I would write that as > "In Python, this first creates an integer object with value 6 and then > binds the name "b" to it. Then it binds the name "a" to the same object. > Thus both "a" and "b" reference the same object, i.e. they are different > names for the same object." > > Bye, Andreas Doing all of this discussion with immutable objects masks the real behavior, as someone can use a false model and seem to justify that model. I don't think you're doing that, but others in the thread are. -- DaveA
[toc] | [prev] | [next] | [standalone]
| From | Andreas Perstinger <andipersti@gmail.com> |
|---|---|
| Date | 2013-06-16 17:02 +0200 |
| Subject | Re: OT: C vs Python terminology |
| Message-ID | <mailman.3445.1371394941.3114.python-list@python.org> |
| In reply to | #48416 |
On 16.06.2013 14:55, Dave Angel wrote: > On 06/16/2013 07:22 AM, Andreas Perstinger wrote: >> On 16.06.2013 08:32, Denis McMahon wrote: >>> C: ^^^^^^^^^ >>> >>> int a, b; >>> b = 6; >>> a = b; >>> >>> In C, this places the numeric value 6 into the memory location identified ^^^^^^^^^^^^^ >>> by the variable "b", >> >> so far so good. >> >>> then copies the value from the location pointed to by "b" into the >>> location pointed to by "a". >> >> Wrong. Neither "a" nor "b" are pointers, thus they don't point to a >> memory location. >> This part should be written as >> "then copies the value at the location identified by "b" to the location >> identified by "a". > > But it doesn't. It binds b to the same object to which a is currently > bound. Are you aware that Denis was talking about the behaviour of C in the above quote? >>> b is a pointer to a memory location containing the value 6 >> > a is a pointer to another memory location also containing the value 6 >> >> Again, neither "a" nor "b" are pointers. >> "b" is the name of a memory location containing the integer value 6. >> "a" is the name of another memory location containing the integer value 6. >> > > Not even close. If you don't like the terms "bound" or "points", the > perhaps you'd be happy with "b" is the name that currently knows how to > find an int object containing 6. That object has no name, and never > will. And it can exist for a long time with no names directly bound to it. Again, Denis was talking about C. Bye, Andreas
[toc] | [prev] | [next] | [standalone]
| From | Dave Angel <davea@davea.name> |
|---|---|
| Date | 2013-06-16 21:58 -0400 |
| Subject | Re: OT: C vs Python terminology |
| Message-ID | <mailman.3466.1371434328.3114.python-list@python.org> |
| In reply to | #48416 |
On 06/16/2013 11:02 AM, Andreas Perstinger wrote: > On 16.06.2013 14:55, Dave Angel wrote: >> On 06/16/2013 07:22 AM, Andreas Perstinger wrote: >> <SNIP> >> But it doesn't. It binds b to the same object to which a is currently >> bound. > > Are you aware that Denis was talking about the behaviour of C in the > above quote? > Nope, missed that. Sorry for the noise. -- DaveA
[toc] | [prev] | [next] | [standalone]
| From | "R. Michael Weylandt" <michael.weylandt@gmail.com> |
|---|---|
| Date | 2013-06-14 09:28 +0100 |
| Message-ID | <mailman.3269.1371198521.3114.python-list@python.org> |
| In reply to | #48077 |
On Fri, Jun 14, 2013 at 9:24 AM, R. Michael Weylandt <michael.weylandt@gmail.com> wrote: > On Fri, Jun 14, 2013 at 9:03 AM, Nick the Gr33k <support@superhost.gr> wrote:> >> >> No clue. since the expression in parenthesis returns 'abcd' how can 'k' >> contained within 'abcd' ? > > No it's not. See both above (where you use 'or' instead) and below > where _you yourself_ show that it's not 'abcd.' s/it's not/it doesn't return/g Typos always and forever, MW
[toc] | [prev] | [next] | [standalone]
| From | Fábio Santos <fabiosantosart@gmail.com> |
|---|---|
| Date | 2013-06-14 09:35 +0100 |
| Message-ID | <mailman.3270.1371198941.3114.python-list@python.org> |
| In reply to | #48077 |
[Multipart message — attachments visible in raw view] — view raw
On 14 Jun 2013 09:09, "Nick the Gr33k" <support@superhost.gr> wrote: > >>> print(name and month and year) > ijkl > > Seems here is returning the last string out of 3 strings, but have no clue why Python doing this. > You have been told this above. All languages kind of do that. Ever seen this command on a shell? mkdir directory && cd directory The shell evaluated the first and if that was truthy it went on to evaluate the second and return that. Now. You've been told countless times that you won't get anything from "not in (a and b and c)", nor from "not in (a or b or c)". Also you have been shown this link and I feel you really need to read it. http://slash7.com/2006/12/22/vampires/ Cheers
[toc] | [prev] | [next] | [standalone]
| From | Nick the Gr33k <support@superhost.gr> |
|---|---|
| Date | 2013-06-14 11:44 +0300 |
| Message-ID | <kpel54$spl$3@news.ntua.gr> |
| In reply to | #48077 |
On 14/6/2013 11:03 πμ, Nick the Gr33k wrote:
> On 14/6/2013 4:14 πμ, Steven D'Aprano wrote:
>> On Thu, 13 Jun 2013 17:26:18 +0300, Νικόλαος Κούρας wrote:
>>
>>> i just want 4 cases to examine so correct execute to be run:
>>>
>>> i'm reading and reading and reading this all over:
>>>
>>> if '-' not in ( name and month and year ):
>>>
>>> and i cant comprehend it.
>>
>> Don't just read it. Open the interactive interpreter and test it.
>>
>> name = "abcd"
>> month = "efgh"
>> year = "ijkl"
>>
>> print(name and month and year)
>>
>> If you run that, you will see what the result of
>> (name and month and year) is. Now, ask yourself:
>>
>> "k" in (name and month and year)
>>
>> True or false? Check your answer:
>>
>> print("k" in (name and month and year))
>
>
> >>> name="abcd"
> >>> month="efgh"
> >>> year="ijkl"
>
> >>> print(name or month or year)
> abcd
>
> Can understand that, it takes the first string out of the 3 strings that
> has a truthy value.
>
> >>> print("k" in (name and month and year))
> True
>
> No clue. since the expression in parenthesis returns 'abcd' how can 'k'
> contained within 'abcd' ?
>
> >>> print(name and month and year)
> ijkl
>
> Seems here is returning the last string out of 3 strings, but have no
> clue why Python doing this.
>
> >>> print("k" in (name and month and year))
> True
> >>>
>
> yes, since expression returns 'ijkl', then the in operator can detect
> the 'k' character within the returned string.
>
Someone want to explain this?
--
What is now proved was at first only imagined!
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-06-14 18:57 +1000 |
| Message-ID | <mailman.3273.1371200264.3114.python-list@python.org> |
| In reply to | #48091 |
On Fri, Jun 14, 2013 at 6:44 PM, Nick the Gr33k <support@superhost.gr> wrote: > Someone want to explain this? Stop writing. Start reading. It has been explained. In the course of a long and adventurous thread in the principal European courts, it has been revealed to you that ... Fill in whatever you like for the rest, it's probably all been revealed at some point already. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Nick the Gr33k <support@superhost.gr> |
|---|---|
| Date | 2013-06-14 12:00 +0300 |
| Message-ID | <kpem3e$spl$4@news.ntua.gr> |
| In reply to | #48093 |
On 14/6/2013 11:57 πμ, Chris Angelico wrote: > On Fri, Jun 14, 2013 at 6:44 PM, Nick the Gr33k <support@superhost.gr> wrote: >> Someone want to explain this? > > Stop writing. Start reading. It has been explained. In the course of a > long and adventurous thread in the principal European courts, it has > been revealed to you that ... > > Fill in whatever you like for the rest, it's probably all been > revealed at some point already. > > ChrisA > Well i do not understand it. Had to use: if '-' not in name + month + year: cur.execute( '''SELECT * FROM works WHERE clientsID = (SELECT id FROM clients WHERE name = %s) and MONTH(lastvisit) = %s and YEAR(lastvisit) = %s ORDER BY lastvisit ASC''', (name, month, year) ) elif '-' not in name + year: cur.execute( '''SELECT * FROM works WHERE clientsID = (SELECT id FROM clients WHERE name = %s) and YEAR(lastvisit) = %s ORDER BY lastvisit ASC''', (name, year) ) elif '-' not in month + year: cur.execute( '''SELECT * FROM works WHERE MONTH(lastvisit) = %s and YEAR(lastvisit) = %s ORDER BY lastvisit ASC''', (month, year) ) elif '-' not in year: cur.execute( '''SELECT * FROM works WHERE YEAR(lastvisit) = %s ORDER BY lastvisit ASC''', year ) to am eit work. but i really wont to understand how 'or' and 'and' works inside an expression. please answer my previous post if you know. -- What is now proved was at first only imagined!
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.lang.python
csiph-web