Israel Brewster writes:
> I have a Flask/UWSGI web app that serves up web socket connections. When a
> web socket connection is created, I want to store a reference to said web
> socket so I can do things like write messages to every connected
> socket/disconnect various sockets/etc. UWSGI, ho
On Fri, 3 Nov 2017 04:22 pm, Paul Rubin wrote:
> Steve D'Aprano writes:
>> for x in something():
>> print(x, end='')
>
> print(''.join(something()))
I hoped that people would recognise a simplified, toy example used only to
illustrate a technique, rather than an exact copy and paste of som
On Thu, 2017-11-02 at 16:31 +, Jon Ribbens wrote:
> On 2017-11-02, Steve D'Aprano wrote:
> > On Fri, 3 Nov 2017 12:39 am, Jon Ribbens wrote:
> > > Why would we want to make the language worse? It is fairly
> > > obvious
> > > what 'else' means,
> >
> > Yes, obvious and WRONG.
>
> Nope, o
02.11.17 12:10, Steve D'Aprano пише:
Occasionally it is useful to loop over a bunch of stuff in the interactive
interpreter, printing them as you go on a single line:
for x in something():
print(x, end='')
If you do that, the prompt overwrites your output, and you get a mess:
py> for x i
On Fri, Nov 3, 2017 at 8:48 PM, Alexey Muranov wrote:
> 'Then' describes what happens next indeed, unless some extraordinary
> situation prevents it from happening, for example:
>
>try:
>go_to_the_bakery()
>then:
>buy_croissants(2)
>except BakeryClosed:
>go_to_t
On 02/11/17 20:24, Chris Angelico wrote:
Thank you. I've had this argument with many people, smart people (like
Steven), people who haven't grokked that all concurrency has costs -
that threads aren't magically more dangerous than other options.
I'm with Steven. To be fair, the danger with thr
On 2017-11-03, Alexey Muranov wrote:
> 'Then' describes what happens next indeed, unless some extraordinary
> situation prevents it from happening, for example:
>
> try:
> go_to_the_bakery()
> then:
> buy_croissants(2)
> except BakeryClosed:
> go_to_the_grocier
On 2017-11-03, Steve D'Aprano wrote:
> On Fri, 3 Nov 2017 03:31 am, Jon Ribbens wrote:
>> No, it's an obvious bug. You have a 'for...else' with no 'break'.
>> Like I said, that should probably be a syntax error.
>
> It should absolutely not be a syntax error. There's no reason for it
> to be a syn
On 03/11/2017 11:49, Jon Ribbens wrote:
On 2017-11-03, Steve D'Aprano wrote:
Right, which is what happens with the for...else block.
No. Ok, so look. It's obvious that you and I have different mental
models of the situation here. You're thinking of 'for...else' as two
arbitrary clauses that
On Fri, 3 Nov 2017 09:13 pm, Serhiy Storchaka wrote:
> What the interpreter or configuration do you use? The standard
> interpreter uses '>>> ' as a prompt.
I have this in my Python startup file:
if (sys.version_info[0] >= 3 and os.name == 'posix'
and os.environ['TERM'] in ['xterm', 'vt1
On Fri, Nov 3, 2017 at 10:49 PM, Jon Ribbens wrote:
> On 2017-11-03, Steve D'Aprano wrote:
>> On Fri, 3 Nov 2017 03:31 am, Jon Ribbens wrote:
>>> No, it's an obvious bug. You have a 'for...else' with no 'break'.
>>> Like I said, that should probably be a syntax error.
>>
>> It should absolutely n
Hi,
Yesterday, while working with redis, i encountered a strange case.
I want to ask why is the following `True`
```
"s" is b"s".decode()
```
while the followings are `False`?
```
"so" is b"so".decode()
"som" is b"som".decode()
"some" is b"some".decode()
```
Or vice versa?
I read that `is` c
On Fri, Nov 3, 2017 at 8:24 PM, Ali Rıza KELEŞ wrote:
> Hi,
>
> Yesterday, while working with redis, i encountered a strange case.
>
> I want to ask why is the following `True`
>
> ```
> "s" is b"s".decode()
> ```
>
> while the followings are `False`?
>
> ```
> "so" is b"so".decode()
> "som" is b"
On Fri, Nov 3, 2017 at 10:26 PM, Rhodri James wrote:
> On 02/11/17 20:24, Chris Angelico wrote:
>>
>> Thank you. I've had this argument with many people, smart people (like
>> Steven), people who haven't grokked that all concurrency has costs -
>> that threads aren't magically more dangerous than
On 03/11/17 14:50, Chris Angelico wrote:
On Fri, Nov 3, 2017 at 10:26 PM, Rhodri James wrote:
On 02/11/17 20:24, Chris Angelico wrote:
Thank you. I've had this argument with many people, smart people (like
Steven), people who haven't grokked that all concurrency has costs -
that threads aren'
On Sat, 4 Nov 2017 01:50 am, Chris Angelico wrote:
> On Fri, Nov 3, 2017 at 10:26 PM, Rhodri James wrote:
>> I'm with Steven. To be fair, the danger with threads is that most people
>> don't understand thread-safety, and in particular don't understand either
>> that they have a responsibility t
On Fri, 2017-11-03 at 22:03 +1100, Chris Angelico wrote:
> On Fri, Nov 3, 2017 at 8:48 PM, Alexey Muranov com> wrote:
> > 'Then' describes what happens next indeed, unless some
> > extraordinary
> > situation prevents it from happening, for example:
> >
> > try:
> > go_to_the_bakery()
On Sat, Nov 4, 2017 at 2:45 AM, Steve D'Aprano
wrote:
> So, all else being equal, which is likely to have more bugs?
>
>
> 1. Multiprocessing code with very little coupling between processes; or
>
> 2. Threaded code with shared data and hence higher coupling between threads?
>
Obviously, option 1
On Sat, Nov 4, 2017 at 3:15 AM, Alexey Muranov wrote:
> On Fri, 2017-11-03 at 22:03 +1100, Chris Angelico wrote:
>> On Fri, Nov 3, 2017 at 8:48 PM, Alexey Muranov > com> wrote:
>> > 'Then' describes what happens next indeed, unless some
>> > extraordinary
>> > situation prevents it from happening,
On 2017-11-03, Chris Angelico wrote:
> On Sat, Nov 4, 2017 at 2:45 AM, Steve D'Aprano
> wrote:
>> So, all else being equal, which is likely to have more bugs?
>>
>>
>> 1. Multiprocessing code with very little coupling between processes; or
>>
>> 2. Threaded code with shared data and hence higher c
On Thu, Nov 2, 2017 at 10:27 AM, Israel Brewster wrote:
>
>> On Nov 1, 2017, at 4:53 PM, Steve D'Aprano
>> wrote:
>>
>> On Thu, 2 Nov 2017 05:53 am, Israel Brewster wrote:
>>
>> [...]
>>> So the end result is that the thread that "updates" the dictionary, and the
>>> thread that initially *popul
On Fri, 3 Nov 2017 10:49 pm, Jon Ribbens wrote:
> On 2017-11-03, Steve D'Aprano wrote:
>> On Fri, 3 Nov 2017 03:31 am, Jon Ribbens wrote:
>>> No, it's an obvious bug. You have a 'for...else' with no 'break'.
>>> Like I said, that should probably be a syntax error.
>>
>> It should absolutely not b
On 2017-11-03, Chris Angelico wrote:
> On Fri, Nov 3, 2017 at 10:49 PM, Jon Ribbens
> wrote:
>>> It should absolutely not be a syntax error. There's no reason for it
>>> to be a syntax error, except to satisfy some arrogant and foolish
>>> idea of purity.
>>
>> It'd be nice if you could be a lit
On Friday 03 November 2017 10:50:13 Chris Angelico wrote:
> On Fri, Nov 3, 2017 at 10:26 PM, Rhodri James
wrote:
> > On 02/11/17 20:24, Chris Angelico wrote:
> >> Thank you. I've had this argument with many people, smart people
> >> (like Steven), people who haven't grokked that all concurrency
On 2017-11-03, Steve D'Aprano wrote:
> The for loop does not necessarily perform a search:
>
> count = 1
> for obj in sequence:
> if count > MAX_OBJECTS:
> print("too many objects, halting")
> break
> process(obj)
> else:
> print("finished")
>
> According to your mental
On Fri, Nov 3, 2017 at 8:32 AM, Chris Angelico wrote:
> On Fri, Nov 3, 2017 at 10:49 PM, Jon Ribbens
> wrote:
>> On 2017-11-03, Steve D'Aprano wrote:
>>> On Fri, 3 Nov 2017 03:31 am, Jon Ribbens wrote:
No, it's an obvious bug. You have a 'for...else' with no 'break'.
Like I said, that
---
Israel Brewster
Systems Analyst II
Ravn Alaska
5245 Airport Industrial Rd
Fairbanks, AK 99709
(907) 450-7293
---
> On Nov 3, 2017, at 7:11 AM, Rhodri James wrote:
>
> On 03/11/17 14:50, Chris Angelico
On 11/03/2017 11:44 AM, Jon Ribbens wrote:
> And that's leading you into confusion, as you've demonstrated.
And indeed I've been led into considerable confusion about the else:
clause over the years. Every time I need to use it, I run a python shell
and try it out to remind myself how it works. H
On 03/11/17 18:12, Israel Brewster wrote:
On Nov 3, 2017, at 7:11 AM, Rhodri James wrote:
People generally understand how to move data around, and the mistakes are
usually pretty obvious when they happen.
I think the existence of this thread indicates otherwise :-) This mistake was
far from
On 11/3/2017 5:24 AM, Ali Rıza KELEŞ wrote:
Hi,
Yesterday, while working with redis, i encountered a strange case.
I want to ask why is the following `True`
```
"s" is b"s".decode()
```
while the followings are `False`?
```
"so" is b"so".decode()
"som" is b"som".decode()
"some" is b"some".de
On Fri, Nov 3, 2017 at 3:25 PM, Stefan Ram wrote:
> Jon Ribbens writes:
>>No, it's an obvious bug. You have a 'for...else' with no 'break'.
>>Like I said, that should probably be a syntax error.
>
> It should make the syntax of Python much more complicated,
> when one would try to encode this
On Sat, 4 Nov 2017 06:15 am, Michael Torrie wrote:
> In fact if you have no break you may as well drop the
> else entirely, because the block will always execute.
That's incorrect. There are multiple ways to exit a loop that will prevent the
`else` block from executing, `break` is only one.
--
On Sat, 4 Nov 2017 05:12 am, Israel Brewster wrote:
[...]
>> People generally understand how to move data around, and the mistakes are
>> usually pretty obvious when they happen.
>
> I think the existence of this thread indicates otherwise :-) This mistake
> was far from obvious, and clearly I di
On 11/03/2017 07:09 PM, Steve D'Aprano wrote:
> On Sat, 4 Nov 2017 06:15 am, Michael Torrie wrote:
>
>> In fact if you have no break you may as well drop the
>> else entirely, because the block will always execute.
>
> That's incorrect. There are multiple ways to exit a loop that will prevent the
On Sat, Nov 4, 2017 at 1:57 PM, Michael Torrie wrote:
> On 11/03/2017 07:09 PM, Steve D'Aprano wrote:
>> On Sat, 4 Nov 2017 06:15 am, Michael Torrie wrote:
>>
>>> In fact if you have no break you may as well drop the
>>> else entirely, because the block will always execute.
>>
>> That's incorrect.
On 11/03/2017 09:06 PM, Chris Angelico wrote:
> On Sat, Nov 4, 2017 at 1:57 PM, Michael Torrie wrote:
>> On 11/03/2017 07:09 PM, Steve D'Aprano wrote:
>>> On Sat, 4 Nov 2017 06:15 am, Michael Torrie wrote:
>>>
In fact if you have no break you may as well drop the
else entirely, because t
Ian Kelly writes:
> Steve was clearly referring to the coder, not the code.
Not at all. Steve was referring specifically to the *idea*:
[A ‘for … else’ structure without a ‘break’] should absolutely not
be a syntax error. There's no reason for it to be a syntax error,
except to sati
37 matches
Mail list logo
