The #python channel only allows registered Freenode users in. You can learn
about registration on Freenode here:
https://freenode.net/kb/answer/registration
Once you've got a registered account you can join #python and should find
many helpful people ready to help you.
On Mon, Aug 12, 2019 at 8:0
On Tue, 13 Aug 2019 at 10:00, Hongyi Zhao wrote:
>
> But I always be put into the #python-unregistered channel as follows:
>
> --
> Now talking on #python-unregistered
> * Topic for #python-unregistered is: Welcome to #python-unregistered!
> You've been put here because #python requires yo
On Mon, 12 Aug 2019 16:13:41 -0700, Paul Rubin wrote:
> It's always worked ok for me.
But I always be put into the #python-unregistered channel as follows:
--
Now talking on #python-unregistered
* Topic for #python-unregistered is: Welcome to #python-unregistered!
You've been put here b
Random832 wrote:
What's not abstract is that if an object has address X and is N bytes
long, those bytes (and any larger subobjects) occupy a contiguous range
of addresses between X and X+(N-1).
If you're talking about Python objects, that's not necessarily
true -- there's no requirement that a
On Fri, Jul 7, 2017 at 8:41 AM, Nathan Ernst wrote:
> Looks like single expression statements are handled a bit differently than
> multiple expression statements:
>
> Python 3.5.2 (default, Nov 17 2016, 17:05:23)
> [GCC 5.4.0 20160609] on linux
> Type "help", "copyright", "credits" or "license" fo
On Thu, Jul 6, 2017 at 12:56 PM, Nathan Ernst wrote:
> In Python, "==" is not a reference equality operator (and I hate Java for
> their misuse of the operator), so I absolutely disagree with using the Java
> description to describe Python's "==" operator, primarily because, well,
> it's wrong. Si
On Fri, Jul 7, 2017, at 10:41, Nathan Ernst wrote:
> Looks like single expression statements are handled a bit differently
> than
> multiple expression statements:
>
> Python 3.5.2 (default, Nov 17 2016, 17:05:23)
> [GCC 5.4.0 20160609] on linux
> Type "help", "copyright", "credits" or "license" f
On Fri, Jul 7, 2017, at 04:12, Gregory Ewing wrote:
> Only if you interpret the word "address" very narrowly.
>
> By the way, even the low-level notion of "address" that C
> programs deal with is, on most modern hardware, a *virtual*
> address that goes through a level of translation before it
> i
Looks like single expression statements are handled a bit differently than
multiple expression statements:
Python 3.5.2 (default, Nov 17 2016, 17:05:23)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> n = 4000; m = 4000; n is m
True
>>> n =
On Fri, Jul 7, 2017 at 9:48 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Fri, Jul 7, 2017 at 7:15 PM, Marko Rauhamaa wrote:
>>> You can only define the semantics of Python (in this case) by
>>> providing an *arbitrary* mapping to an imaginary abstract machine.
>>> There's no way to define
Chris Angelico :
> On Fri, Jul 7, 2017 at 7:15 PM, Marko Rauhamaa wrote:
>> You can only define the semantics of Python (in this case) by
>> providing an *arbitrary* mapping to an imaginary abstract machine.
>> There's no way to define the objective abstraction.
>
> So aside from an artificial se
On Fri, Jul 7, 2017 at 7:15 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Fri, Jul 7, 2017 at 6:43 PM, Marko Rauhamaa wrote:
>>> Python's integer object 0 might be equated with the (mathematical)
>>> natural number 18974387634. Python code would have no way of
>>> introspecting that natura
Chris Angelico :
> On Fri, Jul 7, 2017 at 6:43 PM, Marko Rauhamaa wrote:
>> Python's integer object 0 might be equated with the (mathematical)
>> natural number 18974387634. Python code would have no way of
>> introspecting that natural number.
>>
>> The execution model would determine what prope
On Fri, Jul 7, 2017 at 6:58 PM, Marko Rauhamaa wrote:
> Steve D'Aprano :
>
>> But the Python virtual machine doesn't require objects to have an
>> address at all.
>
> That's an interesting question. Is it possible to define formal
> semantics for Python without the notion of an address (under some
Steve D'Aprano :
> But the Python virtual machine doesn't require objects to have an
> address at all.
That's an interesting question. Is it possible to define formal
semantics for Python without the notion of an address (under some name)?
Ultimately it seems necessary to have an enumerable set (
Steve D'Aprano :
> On Fri, 7 Jul 2017 05:45 pm, Chris Angelico wrote:
>
>> On Fri, Jul 7, 2017 at 4:43 PM, Steve D'Aprano
>> wrote:
>>> On Fri, 7 Jul 2017 01:41 am, Marko Rauhamaa wrote:
In Second-Order Logic, you can define identity directly:
∀x ∀y x = y ↔ ∀P (P(x) ↔ P(y))
>>>
On Fri, Jul 7, 2017 at 6:43 PM, Marko Rauhamaa wrote:
> Steve D'Aprano :
>
>> On Fri, 7 Jul 2017 07:10 am, Marko Rauhamaa wrote:
>>
>>> I believe identity can be defined much better, in numerous isomorphic
>>> ways in fact.
>>>
>>> For example, we could equate each object with a sequence number
>>
On Fri, 7 Jul 2017 06:12 pm, Gregory Ewing wrote:
> Steve D'Aprano wrote:
>> That implies that it is impossible to implement Scheme:
>>
>> - using a programming language where variables and objects may move during
>> their lifetime;
>>
>> - or using a computing device without conventional memory
Steve D'Aprano :
> On Fri, 7 Jul 2017 07:10 am, Marko Rauhamaa wrote:
>
>> I believe identity can be defined much better, in numerous isomorphic
>> ways in fact.
>>
>> For example, we could equate each object with a sequence number
>> (unrelated with its id()). You can define that the "None" obje
On Fri, 7 Jul 2017 06:05 pm, Gregory Ewing wrote:
> Steve D'Aprano wrote:
>> In practice, identity is hardly important in Python, except for a few limited
>> cases, and the prohibition against using `is` when you mean `==`.
>
> On the contrary, it's a very important concept needed to make
> sense
On Fri, 7 Jul 2017 05:45 pm, Chris Angelico wrote:
> On Fri, Jul 7, 2017 at 4:43 PM, Steve D'Aprano
> wrote:
>> On Fri, 7 Jul 2017 01:41 am, Marko Rauhamaa wrote:
>>> In Second-Order Logic, you can define identity directly:
>>>
>>> ∀x ∀y x = y ↔ ∀P (P(x) ↔ P(y))
>>
>> Translating to English:
On Fri, 7 Jul 2017 05:29 pm, Dan Wissme wrote:
> Strange behavior in Python 3.6.0
> >>> i = 3000
> >>> j = 3000
> >>> i is j
> False
> >>> n = 4000 ; m = 4000 ; n is m
> True
The Python interpreter is allowed to cache integers and reuse them. The
interactive interpreter sometimes does so: if you
Steve D'Aprano wrote:
That implies that it is impossible to implement Scheme:
- using a programming language where variables and objects may move during their
lifetime;
- or using a computing device without conventional memory, e.g. implementing
Scheme using hydraulics, DNA computing, clockwork
Marko Rauhamaa wrote:
In Second-Order Logic, you can define identity directly:
∀x ∀y x = y ↔ ∀P (P(x) ↔ P(y))
That looks more like a definition of *equality* to me.
In mathematics, everything is immutable, so there isn't
really any distinction between equality and identity.
--
Greg
--
ht
Steve D'Aprano wrote:
In practice, identity is hardly important in Python, except for a few limited
cases, and the prohibition against using `is` when you mean `==`.
On the contrary, it's a very important concept needed to make
sense of the way things behave when mutation is involved.
Witness
On Fri, Jul 7, 2017 at 5:29 PM, Dan Wissme wrote:
> Strange behavior in Python 3.6.0
i = 3000
j = 3000
i is j
> False
n = 4000 ; m = 4000 ; n is m
> True
Firstly, remember that immutables are allowed, but not required, to be
shared. So this kind of "strange behaviour" is compl
On Fri, Jul 7, 2017 at 4:43 PM, Steve D'Aprano
wrote:
> On Fri, 7 Jul 2017 01:41 am, Marko Rauhamaa wrote:
>> In Second-Order Logic, you can define identity directly:
>>
>> ∀x ∀y x = y ↔ ∀P (P(x) ↔ P(y))
>
> Translating to English:
>
> For all x, for all y, x equals y if and only if for all P
On 07/07/2017 07:42, Steve D'Aprano wrote:
On Fri, 7 Jul 2017 03:05 am, Marko Rauhamaa wrote:
...
[1] It may actually be instinctive -- there are studies that show that even
young babies express surprise when they see something that violates the
intuitive properties of identity. For e
Le 06/07/2017 à 20:56, Nathan Ernst a écrit :
In Python, "==" is not a reference equality operator (and I hate Java for
their misuse of the operator), so I absolutely disagree with using the Java
description to describe Python's "==" operator, primarily because, well,
it's wrong. Simple example:
On Fri, 7 Jul 2017 07:10 am, Marko Rauhamaa wrote:
> I believe identity can be defined much better, in numerous isomorphic
> ways in fact.
>
> For example, we could equate each object with a sequence number
> (unrelated with its id()). You can define that the "None" object is in
> fact the natura
On Fri, 7 Jul 2017 07:10 am, Marko Rauhamaa wrote:
> Steve D'Aprano :
>
>> An address is a concrete location or place, in other words a physical
>> position in some space, while identity is the abstract state or
>> quality of being identical (sameness), in other words a state of
>> being.
>
> Wh
Steve D'Aprano :
> On Fri, 7 Jul 2017 03:38 am, Marko Rauhamaa wrote:
>
>> Notice that Scheme refers directory to conventional RAM:
>>
>> Variables and objects such as pairs, vectors, and strings implicitly
>> denote locations
>
>
> That implies that it is impossible to implement Scheme:
>
> - us
On Fri, 7 Jul 2017 03:38 am, Marko Rauhamaa wrote:
> Notice that Scheme refers directory to conventional RAM:
>
> Variables and objects such as pairs, vectors, and strings implicitly
> denote locations
That implies that it is impossible to implement Scheme:
- using a programming language where
On Fri, 7 Jul 2017 03:05 am, Marko Rauhamaa wrote:
> I believe the concept of an object is among the more difficult things
> for novice programmers to get.
True, but that has nothing to do with object identity. Inheritance, "is-a"
versus "has-a" relationships, when to write len(x) versus x.len()
On Fri, 7 Jul 2017 01:41 am, Marko Rauhamaa wrote:
> Here's how identity is dealt with in First-Order Logic:
>
>https://en.wikipedia.org/wiki/First-order_logic#Semantics>
>
> In other words, identity is mapped to the "sameness" in a domain of
> discourse.
Define "sameness".
> In Second-
Steve D'Aprano :
> On Fri, 7 Jul 2017 08:56 am, Marko Rauhamaa wrote:
>
>> Google finds a Dutch master's thesis from 2009 that gives formal
>> semantics to a subset of Python. I was interested in seeing how it
>> treated identity. Lo and behold:
>>
>>The is operator determines whether its ope
On Fri, 7 Jul 2017 10:34 am, Gregory Ewing wrote:
> Steve D'Aprano wrote:
>> Address refers to a position in space.
>
> Not always. A PO Box number can remain the same when its owner's
> location in space changes.
But the PO box itself does not change.
Pedantically, I guess it could: the post o
On Fri, 7 Jul 2017 08:56 am, Marko Rauhamaa wrote:
> Google finds a Dutch master's thesis from 2009 that gives formal
> semantics to a subset of Python. I was interested in seeing how it
> treated identity. Lo and behold:
>
>The is operator determines whether its operands are the same object.
On Fri, 7 Jul 2017 07:46 am, Chris Angelico wrote:
> A simple name lookup cannot, I believe, be messed with. Nor can a literal.
In principle, you could replace builtins or globals with a custom namespace that
performed some computation on name lookup. You might even be able to insert
some additio
On Fri, Jul 7, 2017 at 10:34 AM, Gregory Ewing
wrote:
> Steve D'Aprano wrote:
>>
>> Address refers to a position in space.
>
>
> Not always. A PO Box number can remain the same when its owner's
> location in space changes. And IP addresses notoriously fail to
> identify physical locations.
A posi
Steve D'Aprano wrote:
Address refers to a position in space.
Not always. A PO Box number can remain the same when its owner's
location in space changes. And IP addresses notoriously fail to
identify physical locations.
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Chris Angelico :
> On Fri, Jul 7, 2017 at 7:10 AM, Marko Rauhamaa wrote:
>> Whether id() returns one such thing or not can't be discerned by a
>> Python program. What's more, for any compliant implementation of id(),
>> you can interpret the returned number as an address in some address
>> space
On Fri, Jul 7, 2017 at 7:10 AM, Marko Rauhamaa wrote:
> Steve D'Aprano :
>
>> An address is a concrete location or place, in other words a physical
>> position in some space, while identity is the abstract state or
>> quality of being identical (sameness), in other words a state of
>> being.
>
> W
Steve D'Aprano :
> An address is a concrete location or place, in other words a physical
> position in some space, while identity is the abstract state or
> quality of being identical (sameness), in other words a state of
> being.
Whether id() returns one such thing or not can't be discerned by a
In Python, "==" is not a reference equality operator (and I hate Java for
their misuse of the operator), so I absolutely disagree with using the Java
description to describe Python's "==" operator, primarily because, well,
it's wrong. Simple example:
With Python 3.5.2 (should hold for any version
Sorry, finger twitch. Wish there were a minute grace period to recall
such mistakes.
On 7/6/2017 2:16 PM, Terry Reedy wrote:
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
On 7/6/2017 11:41 AM, Marko Rauhamaa wrote:
Chris Angelico :
The formal definition is that objects have identities, and that
assignment (including function parameters and return values) gives you
a reference to the same object.
My example didn't contain a single assignment, but a variation of
On Fri, 7 Jul 2017 01:21 am, Marko Rauhamaa wrote:
> Steve D'Aprano :
>
>> On Thu, 6 Jul 2017 07:24 pm, Marko Rauhamaa wrote:
>>
>>> While talking about addresses might or might not be constructive, let
>>> me just point out that there is no outwardly visible distinction
>>> between "address" or
Marko Rauhamaa :
> Notice that Scheme refers directory to conventional RAM:
s/directory/directly/
--
https://mail.python.org/mailman/listinfo/python-list
Ian Kelly :
> On Thu, Jul 6, 2017 at 9:41 AM, Marko Rauhamaa wrote:
>> As a good example of the style I'm looking for, take a look at:
>>
>>https://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html>
>
> Java reference types have basically the same concept of identity as
> Python objects,
On Fri, Jul 7, 2017 at 3:05 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Fri, Jul 7, 2017 at 1:21 AM, Marko Rauhamaa wrote:
>>> What I'm looking for is snippets of Python code that illustrate the
>>> difference.
>>>
>>> That's how you can illustrate the difference between the "==" and "is
Chris Angelico :
> On Fri, Jul 7, 2017 at 1:21 AM, Marko Rauhamaa wrote:
>> What I'm looking for is snippets of Python code that illustrate the
>> difference.
>>
>> That's how you can illustrate the difference between the "==" and "is"
>> operators:
>>
>> >>> ["a"] is ["a"]
>> False
>>
On Thu, Jul 6, 2017 at 9:41 AM, Marko Rauhamaa wrote:
> As a good example of the style I'm looking for, take a look at:
>
>https://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html>
Java reference types have basically the same concept of identity as
Python objects, so I dug around to find
On Fri, Jul 7, 2017 at 1:21 AM, Marko Rauhamaa wrote:
> Steve D'Aprano :
>
>> On Thu, 6 Jul 2017 07:24 pm, Marko Rauhamaa wrote:
>>
>>> While talking about addresses might or might not be constructive, let
>>> me just point out that there is no outwardly visible distinction
>>> between "address" o
On Fri, Jul 7, 2017 at 12:59 AM, Marko Rauhamaa wrote:
>> Or you are using "address" in some abstract sense so that the "address"
>> does not change when the internal representation of the object is moved
>> to another location.
>
> "Address" is just a word. In fact, I don't think there is any def
Marko Rauhamaa writes:
> Jussi Piitulainen:
>
>> For me it's enough to know that it's the object itself that is passed
>> around as an argument, as a returned value, as a stored value, as a
>> value of a variable. This is the basic fact that lets me understand
>> the behaviour and performance of p
On Fri, Jul 7, 2017 at 12:56 AM, MRAB wrote:
> Perhaps you should be thinking of it as passing around the end of a piece of
> string, the other end being tied to the object itself. :-)
You mean like Elbonian currency?
http://dilbert.com/strip/2008-09-15
ChrisA
--
https://mail.python.org/mailma
Chris Angelico :
> The formal definition is that objects have identities, and that
> assignment (including function parameters and return values) gives you
> a reference to the same object.
My example didn't contain a single assignment, but a variation of your
statement would make a good part in
MRAB writes:
> On 2017-07-06 15:29, Jussi Piitulainen wrote:
>> Marko Rauhamaa writes:
>>
>>> While talking about addresses might or might not be constructive,
>>> let me just point out that there is no outwardly visible distinction
>>> between "address" or "identity".
>>
>> With a generational o
Steve D'Aprano :
> On Thu, 6 Jul 2017 07:24 pm, Marko Rauhamaa wrote:
>
>> While talking about addresses might or might not be constructive, let
>> me just point out that there is no outwardly visible distinction
>> between "address" or "identity".
>
> Er, yes there is. Address refers to a positio
Jussi Piitulainen :
> Marko Rauhamaa writes:
>
>> While talking about addresses might or might not be constructive, let
>> me just point out that there is no outwardly visible distinction
>> between "address" or "identity".
>
> With a generational or otherwise compacting garbage collector there
>
On 2017-07-06 15:29, Jussi Piitulainen wrote:
Marko Rauhamaa writes:
While talking about addresses might or might not be constructive, let
me just point out that there is no outwardly visible distinction
between "address" or "identity".
With a generational or otherwise compacting garbage coll
On Thu, Jul 6, 2017 at 7:24 PM, Marko Rauhamaa wrote:
> While talking about addresses might or might not be constructive, let me
> just point out that there is no outwardly visible distinction between
> "address" or "identity".
>
> Equally well, we could replace those words with:
>
>serial num
Marko Rauhamaa writes:
> While talking about addresses might or might not be constructive, let
> me just point out that there is no outwardly visible distinction
> between "address" or "identity".
With a generational or otherwise compacting garbage collector there
would be. I believe that to be a
On Thu, 6 Jul 2017 07:24 pm, Marko Rauhamaa wrote:
> While talking about addresses might or might not be constructive, let me
> just point out that there is no outwardly visible distinction between
> "address" or "identity".
Er, yes there is. Address refers to a position in space. Identity refer
On Thu, 6 Jul 2017 06:51 pm, Dan Wissme wrote:
> So what 'del L[i]' do exactly in memory ? Same as L.pop(i) ? with
> complexity O(n-i) ?
It depends on what L is and what the value of i is. If L is a list, and i is the
last index of the list, then deleting it is quick. If i is 0, then Python has
t
Chris Angelico :
> On Thu, Jul 6, 2017 at 5:35 PM, Jussi Piitulainen
> wrote:
>> Incidentally, let no one point out that ids are not memory addresses.
>> It says in the interactive help that they are (Python 3.4.0):
>> [...]
>
> Sorry, not the case.
> [...]
>
> id(...)
> Return the identity o
Le 06/07/2017 à 09:29, Terry Reedy a écrit :
On 7/6/2017 3:08 AM, Dan Wissme wrote:
I thought that del L[i] would slide L[i+1:] one place to the left,
filling the hole, but :
>>> L
[0, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100]
>>> id(L)
4321967496
>>> id(L[5])# address of 50 ?
4297625504
Chris Angelico writes:
> On Thu, Jul 6, 2017 at 5:35 PM, Jussi Piitulainen
> wrote:
>> Incidentally, let no one point out that ids are not memory addresses.
>> It says in the interactive help that they are (Python 3.4.0):
>>
>> Help on built-in function id in module builtins:
>>
>> id(...)
>>
Le 06/07/2017 à 09:29, Terry Reedy a écrit :
On 7/6/2017 3:08 AM, Dan Wissme wrote:
I thought that del L[i] would slide L[i+1:] one place to the left,
filling the hole, but :
>>> L
[0, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100]
>>> id(L)
4321967496
>>> id(L[5])# address of 50 ?
4297625504
On Thu, Jul 6, 2017 at 5:35 PM, Jussi Piitulainen
wrote:
> Incidentally, let no one point out that ids are not memory addresses.
> It says in the interactive help that they are (Python 3.4.0):
>
> Help on built-in function id in module builtins:
>
> id(...)
> id(object) -> integer
>
> Retu
Dan Wissme writes:
> I thought that del L[i] would slide L[i+1:] one place to the left,
> filling the hole, but :
>
L
> [0, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100]
id(L)
> 4321967496
id(L[5])# address of 50 ?
> 4297625504
del L[2]
id(L[4]) # new address of 50 ?
>
On 7/6/2017 3:08 AM, Dan Wissme wrote:
I thought that del L[i] would slide L[i+1:] one place to the left,
filling the hole, but :
>>> L
[0, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100]
>>> id(L)
4321967496
>>> id(L[5])# address of 50 ?
4297625504
>>> del L[2]
>>> id(L[4]) # new address
> > argument: ... | test '=' test
> Where are you finding that?
This comes from Python-2.6/Grammar/Grammar in the source distribution.
> This tells you that keyword arguments cannot have keywords that aren't
> identifiers:
>
> >>> sum(1=2)
>
> File "", line 1
> SyntaxError: keyword can't be
Thank you for this very clear (and quick) explanation! :-)
Cheers,
Franck
On 19 avr, 08:58, "Martin v. Loewis" wrote:
> # The reason that keywords are test nodes instead of NAME is that using
> # NAME results in an ambiguity. ast.c makes sure it's a NAME.
> argument: test [comp_for] | test '='
> Does any one knows why the grammar is so coded? Any intuition?
The 2.7 Grammar clarifies that:
# The reason that keywords are test nodes instead of NAME is that using
# NAME results in an ambiguity. ast.c makes sure it's a NAME.
argument: test [comp_for] | test '=' test
The ambiguity is this:
On Sun, 18 Apr 2010 23:29:44 -0700, franck wrote:
> Dear all,
>
> I'm wondering why in Python's grammar, keyword arguments are specified
> as:
>
> argument: ... | test '=' test
Where are you finding that?
> I would have expected something like
>
> argument: ... | NAME '=' test
>
>
On Jul 15, 2:04 am, "Sebastian \"lunar\" Wiesner"
<[EMAIL PROTECTED]> wrote:
> Bighead <[EMAIL PROTECTED]>:
>
> > I remember when I did UI Design in PyQt4 for the first time, I found a
> > manual. In it, no "connect" was used. Instead, an OO approach is
> > applied, new UI classes inherit from old
Bighead <[EMAIL PROTECTED]>:
> I remember when I did UI Design in PyQt4 for the first time, I found a
> manual. In it, no "connect" was used. Instead, an OO approach is
> applied, new UI classes inherit from old ones, and all the slot
> functions are automatically connected to some signals, using
On Apr 13, 10:33 pm, "Penny Y." <[EMAIL PROTECTED]> wrote:
> I saw many python programmers add a ';' at the end of each line.
> As good style, should or should not we do coding with that?
Where did you see that?
>
> Thanks.
--
http://mail.python.org/mailman/listinfo/python-list
"Penny Y." <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
|I saw many python programmers add a ';' at the end of each line.
| As good style, should or should not we do coding with that?
NOO...
Read PEP8 for one style guide (for new stdlib code).
--
http://mail.python.or
On Apr 13, 10:33 pm, "Penny Y." <[EMAIL PROTECTED]> wrote:
> I saw many python programmers add a ';' at the end of each line.
> As good style, should or should not we do coding with that?
That's just because their fingers are stuck in C mode. The
recommended style is NOT to use unnecessary semico
In <[EMAIL PROTECTED]>, Gabriel
Genellina wrote:
> At Thursday 7/12/2006 16:46, Roy Smith wrote:
>
>>I see your point. Actually, I think you want to force the sequences to be
>>lists (regardless of what syntax we end up with), on the theory that tuples
>>are for heterogeneous sequences and lists
"John Machin" <[EMAIL PROTECTED]> wrote:
8<---
> > data = struct.unpack("!H4BH20BHI", strMessage)
> >
> > (top, ip1, ip2, ip3, ip4, messageCounter, ackRequired,
> > dataType, utc1, utc2, utc3, utc4, utc5, utc6, utc7, utc8,
> > utc9, utc10, utc11, utc12, st1, st2, s
At Thursday 7/12/2006 16:46, Roy Smith wrote:
I see your point. Actually, I think you want to force the sequences to be
lists (regardless of what syntax we end up with), on the theory that tuples
are for heterogeneous sequences and lists are for homogeneous ones.
Any rationale for this theory
John Machin wrote:
> Roy Smith wrote:
>
> > It would be nice if struct.unpack() had a way to specify unpacking repeated
> > items as a list, ie:
> >
> >data = struct.unpack ("! H 4(B) H 2B 12(B) 6(B) H I", strMessage)
> >(top,
> > ip,
> > messageCounter,
> > ackRequired,
> >
Roy Smith wrote:
> In article <[EMAIL PROTECTED]>,
> "John Machin" <[EMAIL PROTECTED]> wrote:
>
> > Roy Smith wrote:
> >
> > > It would be nice if struct.unpack() had a way to specify unpacking
> > > repeated
> > > items as a list, ie:
> > >
> > >data = struct.unpack ("! H 4(B) H 2B 12(B) 6(
In article <[EMAIL PROTECTED]>,
"John Machin" <[EMAIL PROTECTED]> wrote:
> Roy Smith wrote:
>
> > It would be nice if struct.unpack() had a way to specify unpacking repeated
> > items as a list, ie:
> >
> >data = struct.unpack ("! H 4(B) H 2B 12(B) 6(B) H I", strMessage)
> >(top,
> >
Roy Smith wrote:
> It would be nice if struct.unpack() had a way to specify unpacking repeated
> items as a list, ie:
>
>data = struct.unpack ("! H 4(B) H 2B 12(B) 6(B) H I", strMessage)
>(top,
> ip,
> messageCounter,
> ackRequired,
> dataType,
> utc,
> st,
> n
Michael Yanowitz schreef:
> Hello:
>
>I too don't like large lines. However in the following case, and
> multi-level indentations, I find it unavoidable.
>Here is one huge statement I haven't been able to split onto multiple
> lines.
> What would be the best way to split the following line
In article <[EMAIL PROTECTED]>,
"Fredrik Lundh" <[EMAIL PROTECTED]> wrote:
> Michael Yanowitz wrote:
>
> > What would be the best way to split the following line (Python doesn't like
> > me to split it up between the comma-separated parameters):
> >
> >top, ip1, ip2, ip3, ip4, messageCounter
Fredrik Lundh wrote:
> Michael Yanowitz wrote:
>
> > What would be the best way to split the following line (Python doesn't like
> > me to split it up between the comma-separated parameters):
> >
> >top, ip1, ip2, ip3, ip4, messageCounter, ackRequired, dataType, utc1,
> > utc2, utc3, utc4, utc5
Fredrik Lundh wrote:
> Michael Yanowitz wrote:
>
> > What would be the best way to split the following line (Python doesn't like
> > me to split it up between the comma-separated parameters):
> >
> >top, ip1, ip2, ip3, ip4, messageCounter, ackRequired, dataType, utc1,
> > utc2, utc3, utc4, utc
Michael Yanowitz wrote:
> What would be the best way to split the following line (Python doesn't like
> me to split it up between the comma-separated parameters):
>
>top, ip1, ip2, ip3, ip4, messageCounter, ackRequired, dataType, utc1,
> utc2, utc3, utc4, utc5, utc6, utc7, utc8, utc9, utc10, u
, strMessage)
Thanks in advance:
Michael Yanowitz
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf
Of Ramon Diaz-Uriarte
Sent: Wednesday, December 06, 2006 5:12 PM
To: Steve Bergman
Cc: python-list@python.org
Subject: Re: About the 79 character line recommendation
On 5 Dec 2006 13:28:22 -0800, Steve Bergman <[EMAIL PROTECTED]> wrote:
(...)
>
> I'm finding 100 to be a nice balance. It forces me not to be lazy and
> allow really long lines, but allows me to format so as to make the
> meaning most clear.
>
But if you use some advanced editors (such as Emac
Steve Bergman wrote:
>
> So, I was wondering what more accomplished Python programmers thought
> about this.
I *hate* people using more than 79 chars per line! ;) They look
horrible in emacs
and horrible on print. I never found the need for longer lines. The
limit also acts
as a deterrent against
Olivier Langlois wrote:
> There was a coding standard where I worked and the intention behind this
> requirement was to make the code printer friendly. Printing code source
> with lines longer than 80 chars greatly hinder readability on paper.
>
I don't think I've ever seen Python code printed out
Hello,
for me the 80 (or 79) char border when writing code is a fundamental
rule. Being at University and having to document each project on paper,
it is a must do. i.e. I get code from fellow scolars, that have 160
chars per line, and to get that on paper is disgusting, especially in
C/C++. So pl
Olivier Langlois a écrit :
> Hi,
>
> There was a coding standard where I worked and the intention behind this
> requirement was to make the code printer friendly. Printing code source
> with lines longer than 80 chars greatly hinder readability on paper.
Try using size 10 font in place of size 12
1 - 100 of 112 matches
Mail list logo
