Re: Best way to check if there is internet?

[Peter J. Holzer]

On 2022-02-22 12:31:42 +0400, Abdur-Rahmaan Janhangeer wrote:
> A front end eng sent me this for how to check for the internet in JS
> 
> https://html.spec.whatwg.org/multipage/system-state.html#dom-navigator-online
> 
> But it also says:
> 
> "This attribute is inherently unreliable. A computer can be connected to a
> network without having Internet access."

That actually checks whether the browser is in offline mode. You can set
this mode (in Firefox at least) via File -> Work offline. The browser
will also monitor network interfaces and switch to offline mode if none
(except loopback) are up. But fundamentally it's about the state of the
browser ("... must return false if the user agent will not contact the
network ...") not about whether your computer has "internet access" in
any meaningful sense.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PYT - How can I subscribe to a topic in the mailing list?

[Peter J. Holzer]

On 2022-02-21 12:19:36 +0100, vanyp wrote:
> The option to filter by topic is offered in the mailing list subscription
> customization page, although no option list is given. Topics may have been a
> project that was never implemented.

Topics are a rarely used feature of the mailman mailing list software.
The administrator can configure topics and regular expression to
recognize them. Then mailman will scan each message it received to
assign one or more topics to it. As far as I know I have never been on a
mailinglist where the administrator had configured topics. It seems like
one of those features that seemed like a good idea to the developers but
aren't really used by anyone in practice.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PYT - The expressions described in the Python language reference yield only boolean values

[Peter J. Holzer]

On 2022-02-19 23:28:28 +0100, vanyp wrote:
> *I am trying to learn Python from the grammar given in the Python language
> reference and I am surprised.*
> 
> *Lets start here:*
> 
> *"*
> *6.3.4. Calls*
> 
> A call calls a callable object (e.g., a function
> ) with a possibly
> empty series of arguments
> :
> 
> *call *::= |primary 
> |"("
> [|argument_list 
> |[","]
> | |comprehension 
> |]

With all those links this is very hard to read. Please try to format
your mails in a way that makes them easy to follow.

[...][

> *The first or_test is strange, I assume it should be replaced by expression.*

Nope.

> *But even so I think that the only ways out of the recursion are the or_test
> or the lambda_expr.*
> 
> *And by the grammar, those evaluate to booleans as follows:*

No. A grammar specifies how to parse the text, it doesn't say anything
about the types of these expressions (especially not in a dynamically
typed language like python). 

> *Where did I, or the language reference, go wrong?*

First, you neglected the difference between parsing an expression and
evaluating it.

Secondly, you didn't see the way out. 

For example, let's parse the expression

«f(1+2, 3)»

Can this be a call?

To confirm this, is has to match 

call ::=  primary "(" [argument_list [","] | comprehension] 
")"

which looks plausible, so let's dive in:

primary ::=  atom | attributeref | subscription | slicing | call

atom  ::=  identifier | literal | enclosure

identifier   ::=  xid_start xid_continue*

«f» is an identier which is an atom which is a primary.

Good so far. Now for the argument-list:

argument_list::=  positional_arguments ["," starred_and_keywords] 
...

positional_arguments ::=  positional_item ("," positional_item)*

We have two comma-separated items, good so far. Check «1+2» first

positional_item  ::=  assignment_expression | "*" expression

assignment_expression ::=  [identifier ":="] expression

expression ::=  conditional_expression | lambda_expr

conditional_expression ::=  or_test ["if" or_test "else" expression]

or_test  ::=  and_test | or_test "or" and_test

and_test ::=  not_test | and_test "and" not_test

not_test ::=  comparison | "not" not_test

comparison::=  or_expr (comp_operator or_expr)*

or_expr  ::=  xor_expr | or_expr "|" xor_expr

xor_expr ::=  and_expr | xor_expr "^" and_expr

and_expr ::=  shift_expr | and_expr "&" shift_expr

shift_expr ::=  a_expr | shift_expr ("<<" | ">>") a_expr

a_expr ::=  m_expr | a_expr "+" m_expr | a_expr "-" m_expr

Oof. That was a deep recursion, but we finally found a «+». 
So 1 must be an a_expr and 2 an m_expr. Actually recursing once more reveals
that both can be m_expr:

m_expr ::=  u_expr | m_expr "*" u_expr | m_expr "@" m_expr | ...

u_expr ::=  power | "-" u_expr | "+" u_expr | "~" u_expr

power ::=  (await_expr | primary) ["**" u_expr]

primary ::=  atom | attributeref | subscription | slicing | call

atom  ::=  identifier | literal | enclosure

literal ::=  stringliteral | bytesliteral | integer | floatnumber | 
imagnumber

Ok, they are both integer. 

Then we do basically the same for the second argument and we arrive at
the parse tree:

[warning: fixed width font required]

call
  |
   ---+--
  //  |   \
  ||argument_list  |
  ||positional_arguments   |
  ||   /  | \  |
  ||   positional_item| positional_item|
  ||   assignment_expression  | assignment_expression  |
  ||   expression | expression |
  ||   conditional_expression | conditional_expression |
  ||   or_test| or_test|
  ||   and_test   | and_test   |
  ||   not_test   | not_test   |
  ||   comparison | comparison |
  ||   or_expr| or_expr|
  ||   xor_expr   | xor_expr   |
  ||   and_expr   | and_expr   |
  ||   shift_expr | shift_expr |
  |  

Re: C is it always faster than nump?

[Neil]

Dan Stromberg  wrote:
> On Fri, Feb 25, 2022 at 8:12 AM BELAHCENE Abdelkader <
> abdelkader.belahc...@enst.dz> wrote:
> 
>> Hi,
>> a lot of people think that C (or C++) is faster than python, yes I agree,
>> but I think that's not the case with numpy, I believe numpy is faster than
>> C, at least in some cases.
>>
> 
> This is all "last time I heard".
> 
> numpy is written, in significant part, in Fortran.
> 
> Fortran, especially for matrix math with variable dimensions, can be faster
> than C.
> 
> Fortran, (still last I heard) did not support pointers, which gives Fortran
> compilers the chance to exploit a very nice class of optimizations you
> can't use nearly as well in languages with pointers.
> 
> I used to code C to be built with the "noalias" optimization, to get much
> of the speed of Fortran in C.  But it required using an error prone subset
> of C without good error detection.

Pointers were introduced in Fortran 90.

Neil.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to check if there is internet?

[Robert Latest via Python-list]

Chris Angelico wrote:
> Every language learns from every other.

Except Visual Basic, which didn't learn anything from anywhere, and all that
can be learned from it is how not to do it. Ugh.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to solve the given problem?

[Dennis Lee Bieber]

On Sat, 26 Feb 2022 02:49:15 -0800 (PST), NArshad 
declaimed the following:

>Its better to adjust the feed in the coming next two feeds that is the third 
>and fourth one. Thirty or thirty one units in the third feed and the remaining 
>units which are nine or ten in the fourth feed.  

Is there a question in that?

It's your assignment -- you will have to justify your design to whoever
gave you that assignment. So far all you have is a statement with no
justification.

And you really do need to justify the part where you seem to ignore
"distribute the remaining 40 unit in the rest of the day" and "Try to keep
the distribution similar to the current feeding pattern."

If you really wanted to provide a /generalized/ solution then "40
units" will never appear IN THE CODE. A generalized solution would accept
two lines of input: the original/planned schedule (for the whole day) and,
the implemented schedule up to when the mistake was detected. It would then
generate a new schedule for the rest of the day taking into account what
had already been done. (PLANNED and ACTUAL are input, ADJUSTED is output)

PLANNED:15010030303020201055
ACTUAL: 15060

ADJUSTED:   

Note that a generalized solution would handle

PLANNED:15010030303020201055
ACTUAL: 15060  30

ADJUSTED:   

where the mistake was on the second feed, but not discovered until after
the third feed.


-- 
Wulfraed Dennis Lee Bieber AF6VN
wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: C is it always faster than nump?

[Dennis Lee Bieber]

On Fri, 25 Feb 2022 21:44:14 -0800, Dan Stromberg 
declaimed the following:

>Fortran, (still last I heard) did not support pointers, which gives Fortran
>compilers the chance to exploit a very nice class of optimizations you
>can't use nearly as well in languages with pointers.
>
Haven't looked much at Fortran-90/95 then... 

Variable declaration gained a POINTER qualifier, and there is an
ALLOCATE intrinsic to obtain memory.

And with difficulty one could get the result in DEC/VMS FORTRAN-77
since DEC implemented (across all their language compilers) intrinsics
controlling how arguments are passed -- overriding the language native
passing: 
CALL XYZ(%val(M))
would actually pass the value of M, not Fortran default address-of, with
the result that XYZ would use that value /as/ the address of the actual
argument. (Others were %ref() and %descr() -- descriptor being a small
structure with the address reference along with, say, upper/lower bounds;
often used for strings).



-- 
Wulfraed Dennis Lee Bieber AF6VN
wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: One-liner to merge lists?

[Dan Stromberg]

On Fri, Feb 25, 2022 at 3:15 PM Chris Angelico  wrote:

> But ultimately, that's still the same as sum(), and it's no more
> readable than chain(), so I'd still be inclined to go with chain and
> then wrap it in a function if you need the clarity.
>

"Need" the clarity?  Please tell me you don't think clarity is for the
feeble minded.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: One-liner to merge lists?

[Chris Angelico]

On Sun, 27 Feb 2022 at 16:35, Dan Stromberg  wrote:
>
>
> On Fri, Feb 25, 2022 at 3:15 PM Chris Angelico  wrote:
>>
>> But ultimately, that's still the same as sum(), and it's no more
>> readable than chain(), so I'd still be inclined to go with chain and
>> then wrap it in a function if you need the clarity.
>
>
> "Need" the clarity?  Please tell me you don't think clarity is for the feeble 
> minded.
>

It's more about whether you consider that list(chain(...)) is a clear
and readable idiom, or you prefer to give a name to it. Not every
two-operation action needs its own name.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list