[issue215900] difference between pre and sre for buggy expressions

[admin]

Change by admin :


--
github: None -> 33257

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue462270] sub-tle difference between pre and sre

[admin]

Change by admin :


--
github: None -> 35187

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue215900] difference between pre and sre for buggy expressions

[admin]

Change by admin :


___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue215894] Difference between dos_8x3 and dos-8x3

[admin]

Change by admin :


___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue215894] Difference between dos_8x3 and dos-8x3

[admin]

Change by admin :


--
github: None -> 33255

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14336] Difference between pickle implementations for function objects

[Irit Katriel]

Change by Irit Katriel :


--
resolution:  -> wont fix
stage:  -> resolved
status: pending -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36099] Clarify the difference between mu and xbar in the statistics documentation

[Irit Katriel]

Change by Irit Katriel :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> clarify meaning of xbar and mu in pvariance/variance of 
statistics module

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Subtle difference between any(a list) and any(a generator) with Python 3.9

[Chris Angelico]

On Fri, Jul 30, 2021 at 5:40 AM Terry Reedy  wrote:
> Since the 'two ways' involve the new :=, I have no idea what 'two ways'
> and 'same result' you mean before :=.
>

I'm not sure, but I think that a lot of people read patch notes as if
they say "this is how everyone needs to do things now", and then blame
or credit the newest features with everything that happens.

Personally, I'd search for the comments like this:

for line in lines:
if line.startswith("#"):
... # whatever you do if there is one
break
else:
... # whatever you do if there isn't one

But if you have to do it with a one-liner, much cleaner to use next on
your filter:

comment = next((l for l in lines if l.startswith("#")). None)

Neither of these depends on :=. I don't know what "two ways" there
are, but capturing the first element that matches a filter is a pretty
normal thing to do.

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

Re: Subtle difference between any(a list) and any(a generator) with Python 3.9

[Terry Reedy]

On 7/29/2021 5:39 AM, Unknown wrote:

Hello

Reading PEP572 about Python 3.9 assignment expressions,
I discovered a subtle difference between any(a list)
and any(a generator)

see:

 >>> lines = ["azerty", "#qsdfgh", "wxcvbn"]
 >>> any((comment := line).startswith('#') for line in lines)
True
 >>> comment
"#qsdfgh"

 >>> any([(comment := line).startswith('#') for line in lines])


Same as

>>> booleans = [(comment := line).startswith('#') for line in lines]
>>> # comment == last item.
>>> any(booleans) # Iteration though booleans stops at 1st True.

> True
  >>> comment

'wxcvbn'

The two code snippets which seems very similar provide a
different value for "comment".

When "any" deals with a generator, it stops as soon it finds
a True value and returns True.

When "any" deals with a list, the whole list is calculated
first, and then "any" looks for a True.

Before 3.9 and the walrus operator, the two ways always provide
the same result, in a faster way with a generator.


Since the 'two ways' involve the new :=, I have no idea what 'two ways' 
and 'same result' you mean before :=.



With 3.9 and the walrus operator, result can be different




--
Terry Jan Reedy

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

Re: Subtle difference between any(a list) and any(a generator) with Python 3.9

[Chris Angelico]

On Thu, Jul 29, 2021 at 7:49 PM ast  wrote:
>
> Hello
>
> Reading PEP572 about Python 3.9 assignment expressions,
> I discovered a subtle difference between any(a list)
> and any(a generator)
>
> see:
>
>  >>> lines = ["azerty", "#qsdfgh", "wxcvbn"]
>  >>> any((comment := line).startswith('#') for line in lines)
> True
>  >>> comment
> "#qsdfgh"
>
>  >>> any([(comment := line).startswith('#') for line in lines])
> True
>  >>> comment
> 'wxcvbn'

"any" is irrelevant here. What you're seeing is that a list
comprehension is evaluated fully, and a generator expression isn't.
That's exactly what they're meant to do :)

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

Subtle difference between any(a list) and any(a generator) with Python 3.9

[ast]

Hello

Reading PEP572 about Python 3.9 assignment expressions,
I discovered a subtle difference between any(a list)
and any(a generator)

see:

>>> lines = ["azerty", "#qsdfgh", "wxcvbn"]
>>> any((comment := line).startswith('#') for line in lines)
True
>>> comment
"#qsdfgh"

>>> any([(comment := line).startswith('#') for line in lines])
True
>>> comment
'wxcvbn'

The two code snippets which seems very similar provide a
different value for "comment".

When "any" deals with a generator, it stops as soon it finds
a True value and returns True.

When "any" deals with a list, the whole list is calculated
first, and then "any" looks for a True.

Before 3.9 and the walrus operator, the two ways always provide
the same result, in a faster way with a generator.

With 3.9 and the walrus operator, result can be different








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

[issue23750] doc: Clarify difference between os.system/subprocess.call in section "Replacing os.system()"

[Senthil Kumaran]

Senthil Kumaran  added the comment:


New changeset 390bfe044531a813722919933116ed37fe321861 by Miss Islington (bot) 
in branch '3.9':
bpo-23750: Document os-system, subprocess. Patch by Martin Panter. (GH-26016) 
(GH-26041)
https://github.com/python/cpython/commit/390bfe044531a813722919933116ed37fe321861


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23750] doc: Clarify difference between os.system/subprocess.call in section "Replacing os.system()"

[Senthil Kumaran]

Change by Senthil Kumaran :


--
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23750] doc: Clarify difference between os.system/subprocess.call in section "Replacing os.system()"

[Senthil Kumaran]

Senthil Kumaran  added the comment:


New changeset 6fc6f4366d02412e3424d2a6da43a28d8f479d7b by Miss Islington (bot) 
in branch '3.10':
bpo-23750: Document os-system, subprocess. Patch by Martin Panter. (GH-26016) 
(GH-26040)
https://github.com/python/cpython/commit/6fc6f4366d02412e3424d2a6da43a28d8f479d7b


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23750] doc: Clarify difference between os.system/subprocess.call in section "Replacing os.system()"

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 6.0 -> 7.0
pull_requests: +24685
pull_request: https://github.com/python/cpython/pull/26040

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23750] doc: Clarify difference between os.system/subprocess.call in section "Replacing os.system()"

[miss-islington]

Change by miss-islington :


--
pull_requests: +24686
pull_request: https://github.com/python/cpython/pull/26041

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23750] doc: Clarify difference between os.system/subprocess.call in section "Replacing os.system()"

[Senthil Kumaran]

Senthil Kumaran  added the comment:

Does anyone know what the return value 768 signify here?

--
nosy: +orsenthil

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23750] doc: Clarify difference between os.system/subprocess.call in section "Replacing os.system()"

[So Ukiyama]

So Ukiyama  added the comment:

I created a PR which apply Martin Panter's patch.

So If I have offended you with my rudeness, I hope you will forgive me for 
taking this down.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23750] doc: Clarify difference between os.system/subprocess.call in section "Replacing os.system()"

[So Ukiyama]

Change by So Ukiyama :


--
nosy: +uniocto
nosy_count: 4.0 -> 5.0
pull_requests: +24666
pull_request: https://github.com/python/cpython/pull/26016

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23750] doc: Clarify difference between os.system/subprocess.call in section "Replacing os.system()"

[Irit Katriel]

Irit Katriel  added the comment:

The patch needs to be converted to a github PR.

--
keywords: +easy
nosy: +iritkatriel
title: Clarify difference between os.system/subprocess.call in section 
"Replacing os.system()" -> doc: Clarify difference between 
os.system/subprocess.call in section "Replacing os.system()"
versions: +Python 3.10, Python 3.11, Python 3.9 -Python 2.7, Python 3.4, Python 
3.5, Python 3.6

___
Python tracker 
<https://bugs.python.org/issue23750>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27886] Docs: the difference between Path.rename() and Path.replace() is not obvious

[Eryk Sun]

Eryk Sun  added the comment:

The pathlib documentation of Path.rename() says "[o]n Unix, if target exists 
and is a file, it will be replaced silently if the user has permission". This 
leaves the behavior on Windows in question. The reader has to scroll down to 
the correspondence table to link to the documentation of os.rename() and 
presume that Path.rename() also raises FileExistsError for this case. The 
Path.rename() docs should just state upfront that "[o]n Windows, if target 
exists, FileExistsError will be raised".

--
components: +Library (Lib)
title: Docs: the difference between rename and replace is not obvious -> Docs: 
the difference between Path.rename() and Path.replace() is not obvious
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.5, Python 3.6

___
Python tracker 
<https://bugs.python.org/issue27886>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27886] Docs: the difference between rename and replace is not obvious

[Eryk Sun]

Change by Eryk Sun :


--
Removed message: https://bugs.python.org/msg273845

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17437] Difference between open and codecs.open

[Irit Katriel]

Change by Irit Katriel :


--
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.2, Python 3.3, Python 
3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42320] unexpected difference between map and list

[Pierre van de Laar]

Pierre van de Laar  added the comment:

Not a bug: tuple is an iterator but an iterator is not a tuple.
Yet iterators are often accepted during initialization...

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42320] unexpected difference between map and list

[Pierre van de Laar]

Pierre van de Laar  added the comment:

Zip didn't contain the test cases from the tests directory (sorry for that)

--
Added file: https://bugs.python.org/file49592/tests.zip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42320] unexpected difference between map and list

[Pierre van de Laar]

New submission from Pierre van de Laar :

On windows, with python 3.9, with unittests,

My test case fails when I use the following lines of code
```
result = map(lambda x: self.substitute_in_expression(x),
 sequence.sequence)
```
It works fine with
```
result = list()
for x in sequence.sequence:
 result.append(self.substitute_in_expression(x))
```

Note that result is used as input for an inherited class instantiation:
```
sequence_type = type(sequence)
return sequence_type(result)
```
The classes are constructed using the dataclass decorator!


I have unfortunately not have time to make a small reproducer.
So I just send the whole project.

--
files: bug.zip
messages: 380742
nosy: Pierre van de Laar
priority: normal
severity: normal
status: open
title: unexpected difference between map and list
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file49591/bug.zip

___
Python tracker 
<https://bugs.python.org/issue42320>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27886] Docs: the difference between rename and replace is not obvious

[Ezio Melotti]

Change by Ezio Melotti :


--
nosy: +ezio.melotti

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Puzzling difference between lists and tuples

[Chris Angelico]

On Mon, Sep 21, 2020 at 10:14 PM Serhiy Storchaka  wrote:
>
> 18.09.20 03:55, Chris Angelico пише:
> > On Fri, Sep 18, 2020 at 10:53 AM Grant Edwards
> >  wrote:
> >> Yea, the syntax for tuple literals has always been a bit of an ugly
> >> spot in Python.  If ASCII had only had one more set of open/close
> >> brackets...
> >
> > ... then I'd prefer them to be used for sets, actually. I think the
> > set/dict collision is more weird than the tuple/grouping one.
> >
> > Now, if only ASCII had *two* more sets of open/close brackets...
>
> Then I would use them for sets and frozensets.
>

Ahem. AMONG the needs for additional types of brackets are such
diverse types as.

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

Re: Puzzling difference between lists and tuples

[Serhiy Storchaka]

18.09.20 03:55, Chris Angelico пише:
> On Fri, Sep 18, 2020 at 10:53 AM Grant Edwards
>  wrote:
>> Yea, the syntax for tuple literals has always been a bit of an ugly
>> spot in Python.  If ASCII had only had one more set of open/close
>> brackets...
> 
> ... then I'd prefer them to be used for sets, actually. I think the
> set/dict collision is more weird than the tuple/grouping one.
> 
> Now, if only ASCII had *two* more sets of open/close brackets...

Then I would use them for sets and frozensets.

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

Re: Puzzling difference between lists and tuples

[Cameron Simpson]

On 20Sep2020 20:33, Avi Gross  wrote:
>('M','R','A','B') is correct. I appreciate the correction. I did not look to
>see the content of what I created, just the type!
>
 a = tuple("first")
 a
>('f', 'i', 'r', 's', 't')
 type(a)
>
>
>But I thought adding a comma would help and it does not!

Ah, the comma is for an expression. But you made a function call (well, 
"tuple" is a type and types are callable to make instances).

In a function call the parmeter separating commas have higher precedence 
than the commas with defines a tuple, you you've made a function call 
with one argument "first", not a function call with one _tuple_ argument 
("first",).

Consider:

foo(1, 2)

That supplies 2 arguments, not a single tuple.

As with other situations where the default precedence groups things in a 
different way from your intent, brackets get required here if you want 
to express a tuple.

This:

foo( (1,2) )

isn't notionally different from needing brakcets to express this:

(3+5) * 8

which means something else without its brackets.

Also, function calls allow you to include a trailing comma because it 
helps with code. Consider the following bigger call:

x = foo(
1,
2,
fred=5,
)

laid out on separate lines for readability (a little redundant here, but 
some complex function calls, or those exceeding the deired line length, 
are often folded this way).

Bu allowing a trailing comma we get consistent formatting and nicer 
diffs. If a trailing comma were forbidden, the dopping "fred=5" with 
produce a diff removing not just that line but also the comma on the 
preceeding line. Ugly and noisy.

Cheers,
Cameron Simpson 
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: Puzzling difference between lists and tuples

[Avi Gross via Python-list]

('M','R','A','B') is correct. I appreciate the correction. I did not look to
see the content of what I created, just the type!

>>> a = tuple("first")
>>> a
('f', 'i', 'r', 's', 't')
>>> type(a)


But I thought adding a comma would help and it does not!

>>> b = tuple("first",)
>>> b
('f', 'i', 'r', 's', 't')

Yet something this simple without invoking tuple(), works!

>>> c = 'first',
>>> c
('first',)

So I read the manual page and tuple takes an iterable as an argument and
treats a string as an iterator on characters! It is not a simple
initializer. 

I got around it, sort of, using n array with a single object of type string
in it so the iterator is iterating at a different level.

>>> d = ["first"]
>>> tuple(d)
('first',)
>>> tuple(["first"])
('first',)

I understand the design choice and can imagine there may be another function
that initializes a tuple more directly in some module.

Returning to lurking mode ...

-Original Message-----
From: Python-list  On
Behalf Of MRAB
Sent: Sunday, September 20, 2020 7:35 PM
To: python-list@python.org
Subject: Re: Puzzling difference between lists and tuples

On 2020-09-20 23:59, Avi Gross via Python-list wrote:
> There is a simple and obvious way to make sure you have a tuple by
invoking the keyword/function in making it:
> 
>>>> a=('first')
>>>> type(a)
> 
> 
>>>> a=("first",)
>>>> type(a)
> 
> 
>>>> a=tuple("first")
>>>> type(a)
> 
> 
> That seems more explicit than adding a trailing comma. It also is a simple
way to make an empty tuple but is there any penalty for using the function
tuple()?
> 
[snip]
 >>> tuple("first")
('f', 'i', 'r', 's', 't')

Not the same as ("first",).

A simpler way to make an empty tuple is just ().
-- 
https://mail.python.org/mailman/listinfo/python-list

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

Re: Puzzling difference between lists and tuples

[Greg Ewing]

On 21/09/20 10:59 am, Avi Gross wrote:

a=tuple("first")
type(a)



That seems more explicit than adding a trailing comma.


It doesn't do what you want, though:

>>> a = tuple("first")
>>> print(a)
('f', 'i', 'r', 's', 't')

If you really want to use tuple() to create a 1-tuple without
using a trailing comma, you can do it this way:

>>> a = tuple(["first"])
>>> print(a)
('first',)

But this costs you both a list creation and a tuple() call.
On my machine it seems to be about 17 times slower than using
a trailing comma:

>>> timeit.repeat("tuple(['first'])")
[0.1774688908953, 0.1768788059062, 0.1768771102082, 
0.176763284033, 0.1768448921963]

>>> timeit.repeat("('first',)")
[0.0117392889055, 0.01156933400708, 0.01158800017473, 
0.01156976132486, 0.01157938358281]


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

Re: Puzzling difference between lists and tuples

[MRAB]

On 2020-09-20 23:59, Avi Gross via Python-list wrote:

There is a simple and obvious way to make sure you have a tuple by invoking the 
keyword/function in making it:


a=('first')
type(a)




a=("first",)
type(a)




a=tuple("first")
type(a)



That seems more explicit than adding a trailing comma. It also is a simple way 
to make an empty tuple but is there any penalty for using the function tuple()?


[snip]
>>> tuple("first")
('f', 'i', 'r', 's', 't')

Not the same as ("first",).

A simpler way to make an empty tuple is just ().
--
https://mail.python.org/mailman/listinfo/python-list

RE: Puzzling difference between lists and tuples

[Avi Gross via Python-list]

There is a simple and obvious way to make sure you have a tuple by invoking the 
keyword/function in making it:

>>> a=('first')
>>> type(a)


>>> a=("first",)
>>> type(a)


>>> a=tuple("first")
>>> type(a)


That seems more explicit than adding a trailing comma. It also is a simple way 
to make an empty tuple but is there any penalty for using the function tuple()?


-Original Message-
From: Python-list  On 
Behalf Of "???"
Sent: Saturday, September 19, 2020 11:39 PM
To: python-list@python.org
Subject: Re: Puzzling difference between lists and tuples

William Pearson  writes:

> ...
> for n in ('first'):
> print n
>
>
> ... but "f","i","r","s","t" in the second.

#+BEGIN_SRC: python
for n in ('first',):
print n
#+BEGIN_SRC

Then, that will print 'first'. And please use Python3...

Sincerely, Byung-Hee

-- 
^고맙습니다 _救濟蒼生_ 감사합니다_^))//
-- 
https://mail.python.org/mailman/listinfo/python-list

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

sorry for typo (Was: Re: Puzzling difference between lists and tuples)

[황병희]

> #+BEGIN_SRC: python
> for n in ('first',):
> print n
> #+BEGIN_SRC

The last 'BEGIN_SRC' should be 'END_SRC' so sorry ;;;

-- 
^고맙습니다 _救濟蒼生_ 감사합니다_^))//
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Puzzling difference between lists and tuples

[황병희]

William Pearson  writes:

> ...
> for n in ('first'):
> print n
>
>
> ... but "f","i","r","s","t" in the second.

#+BEGIN_SRC: python
for n in ('first',):
print n
#+BEGIN_SRC

Then, that will print 'first'. And please use Python3...

Sincerely, Byung-Hee

-- 
^고맙습니다 _救濟蒼生_ 감사합니다_^))//
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Puzzling difference between lists and tuples

[Greg Ewing]

On 19/09/20 6:49 am, Grant Edwards wrote:


There must be a few more sets of brackets in Unicode...


Quite a lot, actually. The character browser in MacOSX is currently
showing me 17, not including the ones that are built up from
multiple characters.

Some of them could be easily confused with normal brackets, but
there are a few interesting ones, such as LEFT/RIGHT WHITE/BLACK
LENTICULAR BRACKET and LEFT/RIGHT TORTOISE SHELL BRACKET.

〖 〗【 】〔 〕
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Puzzling difference between lists and tuples

[Grant Edwards]

On 2020-09-18, Chris Angelico  wrote:
> On Fri, Sep 18, 2020 at 10:53 AM Grant Edwards
> wrote:
>>
>> On 2020-09-17, MRAB  wrote:
>> >> The only time the parentheses are required for tuple building is when
>> >> they would otherwise not be interpreted that way:
>> >>
>> > They're needed for the empty tuple, which doesn't have a comma.
>> >
>> >> some_func('first', 'second')   # some_func called with two str args
>> >>
>> >> some_func(('first', 'second')) # some_func called with one tuple arg
>>
>> Yea, the syntax for tuple literals has always been a bit of an ugly
>> spot in Python.  If ASCII had only had one more set of open/close
>> brackets...
>
> ...then I'd prefer them to be used for sets, actually. I think the
> set/dict collision is more weird than the tuple/grouping one.
>
> Now, if only ASCII had *two* more sets of open/close brackets...

Rigth. I had forgotten about sets -- they're still a "new" feature in
my mind, and I rarely seem to run into situations where I use them.

There must be a few more sets of brackets in Unicode...

--
Grant


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

Re: Puzzling difference between lists and tuples

[Chris Angelico]

On Fri, Sep 18, 2020 at 10:53 AM Grant Edwards
 wrote:
>
> On 2020-09-17, MRAB  wrote:
> >> The only time the parentheses are required for tuple building is when
> >> they would otherwise not be interpreted that way:
> >>
> > They're needed for the empty tuple, which doesn't have a comma.
> >
> >> some_func('first', 'second')   # some_func called with two str args
> >>
> >> some_func(('first', 'second')) # some_func called with one tuple arg
>
> Yea, the syntax for tuple literals has always been a bit of an ugly
> spot in Python.  If ASCII had only had one more set of open/close
> brackets...

... then I'd prefer them to be used for sets, actually. I think the
set/dict collision is more weird than the tuple/grouping one.

Now, if only ASCII had *two* more sets of open/close brackets...

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

Re: Puzzling difference between lists and tuples

[Grant Edwards]

On 2020-09-17, MRAB  wrote:
>> The only time the parentheses are required for tuple building is when
>> they would otherwise not be interpreted that way:
>> 
> They're needed for the empty tuple, which doesn't have a comma.
>
>> some_func('first', 'second')   # some_func called with two str args
>> 
>> some_func(('first', 'second')) # some_func called with one tuple arg

Yea, the syntax for tuple literals has always been a bit of an ugly
spot in Python.  If ASCII had only had one more set of open/close
brackets...

--
Grant



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

Re: Puzzling difference between lists and tuples

[Ethan Furman]

On 9/17/20 10:43 AM, MRAB wrote:

On 2020-09-17 17:47, Ethan Furman wrote:



The only time the parentheses are required for tuple building is when
they would otherwise not be interpreted that way:


They're needed for the empty tuple, which doesn't have a comma.


Ah, right.  Thanks.

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

Re: Puzzling difference between lists and tuples

[MRAB]

On 2020-09-17 17:47, Ethan Furman wrote:

On 9/17/20 8:24 AM, William Pearson wrote:


I am puzzled by the reason for this difference between lists and tuples.

A list of with multiple strings can be reduced to a list with one string with 
the expected results:



for n in ['first']:
 print n


['first'] is a list.


for n in ('first'):
 print n


('first') is not a tuple.  The tuple operator is actually the comma:

  >>> not_a_tuple = ('first')
  >>> type(not_a_tuple)


  >>> is_a_tuple = 'first',
  >>> type(is_a_tuple)


I tend to use both as it makes it stand out a bit more:

  >>> still_a_tuple = ('first', )
  >>> type(still_a_tuple)


The only time the parentheses are required for tuple building is when
they would otherwise not be interpreted that way:


They're needed for the empty tuple, which doesn't have a comma.


some_func('first', 'second')   # some_func called with two str args

some_func(('first', 'second')) # some_func called with one tuple arg


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

Re: Puzzling difference between lists and tuples

[Richard Damon]

On 9/17/20 11:24 AM, William Pearson wrote:
> I am puzzled by the reason for this difference between lists and tuples.
>
> A list of with multiple strings can be reduced to a list with one string with 
> the expected results:
>
> for n in ['first','second']:
> print n
>
> for n in ['first']:
> print n
>
> The first loop prints "first", "second", and the second prints "first".
>
> 
>
> This is not true for a tuple:
>
> for n in ('first','second'):
> print n
>
> for n in ('first'):
> print n
>
>
> prints "first", "second" in the first case, but "f","i","r","s","t" in the 
> second.
>
> Where is this inconsistency explained?
>
Parenthesis don't always make a tuple (and in fact aren't needed to make
them)

('first') is just the string value 'first', inside a set of parenthesis
to possible affect order of operations.

For 1 element tuples, you need a trailing comma, like ('first,) and in
many places it also could be just 'first',

just like your first example could be just for n in 'first', 'second':

-- 
Richard Damon

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

Re: Puzzling difference between lists and tuples

[Ethan Furman]

On 9/17/20 8:24 AM, William Pearson wrote:


I am puzzled by the reason for this difference between lists and tuples.

A list of with multiple strings can be reduced to a list with one string with 
the expected results:



for n in ['first']:
 print n


['first'] is a list.


for n in ('first'):
 print n


('first') is not a tuple.  The tuple operator is actually the comma:

>>> not_a_tuple = ('first')
>>> type(not_a_tuple)


>>> is_a_tuple = 'first',
>>> type(is_a_tuple)


I tend to use both as it makes it stand out a bit more:

>>> still_a_tuple = ('first', )
>>> type(still_a_tuple)


The only time the parentheses are required for tuple building is when 
they would otherwise not be interpreted that way:


some_func('first', 'second')   # some_func called with two str args

some_func(('first', 'second')) # some_func called with one tuple arg

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

Re: Puzzling difference between lists and tuples

[2QdxY4RzWzUUiLuE]

On 2020-09-17 at 09:24:57 -0600,
William Pearson  wrote:

> for n in ('first'):

That's not a tuple.  That's a string.

Try it this way:

   for n in ('first',): # note the trailing comma
   print n

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

Puzzling difference between lists and tuples

[William Pearson]

I am puzzled by the reason for this difference between lists and tuples.

A list of with multiple strings can be reduced to a list with one string with 
the expected results:

for n in ['first','second']:
print n

for n in ['first']:
print n

The first loop prints "first", "second", and the second prints "first".



This is not true for a tuple:

for n in ('first','second'):
print n

for n in ('first'):
print n


prints "first", "second" in the first case, but "f","i","r","s","t" in the 
second.

Where is this inconsistency explained?

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

matplotlib: Difference between Axes and AxesSubplot

[ast]

Hello

It's not clear to me what the differences between
Axes and AxesSubplot classes are

AxesSubplot is a sub class of Axes

It is possible to draw in objects of both type with
plot, scatter ...

Axes object seems to be able to be inserted in AxesSubplot object
(It is strange because AxesSubplot is a sub class of Axes)

Here is a piece of code using both.

import matplotlib.pyplot as pyplot

figure = pyplot.figure()
axes = figure.add_subplot(111) # Renvoie un objet AxesSubplot, sous 
classe de Axes

axes.scatter(range(5), [x ** 2 for x in range(5)])
axes.set_xlim(0, 4)
axes.set_xlabel('axe des x')
axes2 = figure.add_axes([0.3, 0.5, 0.3, 0.3]) # renvoie un objet Axes
axes2.patch.set_color('lightyellow')
axes2.plot(range(5), range(5))

and the figure it produces:

http://www.python-simple.com/img/img32.png
--
https://mail.python.org/mailman/listinfo/python-list

Re: Is there a difference between python

[Eryk Sun]

On 4/5/20, Malcolm Greene  wrote:
> Is there a difference between the following 2 ways to launch a console-less
> script under Windows?
>
> python 

Re: Is there a difference between python

[David L Neil via Python-list]

On 6/04/20 10:35 AM, Malcolm Greene wrote:

Is there a difference between the following 2 ways to launch a console-less 
script under Windows?

python 

Re: Is there a difference between python

[Mike Dewhirst]

On 6/04/2020 8:35 am, Malcolm Greene wrote:

Is there a difference between the following 2 ways to launch a console-less 
script under Windows?

python 

Is there a difference between python

[Malcolm Greene]

Is there a difference between the following 2 ways to launch a console-less 
script under Windows?

python 

Re: Have you some experience / link about difference between Python builded with gcc and clang?

[Marco Sulla]

Well, I suppose we have a winner:

pyperf_bench_3_8_gcc_9_2.json
=

Performance version: 1.0.0
Report on Linux-4.15.0-76-generic-x86_64-with-glibc2.27
Number of logical CPUs: 4
Start date: 2020-03-13 19:36:17.585796
End date: 2020-03-13 20:35:09.605718

pyperf_bench_3_8_clang_9.json
=

Performance version: 1.0.0
Report on Linux-4.15.0-76-generic-x86_64-with-glibc2.27
Number of logical CPUs: 4
Start date: 2020-03-13 20:55:54.239018
End date: 2020-03-13 21:59:19.778522

+-+---+---+--+-+
| Benchmark   | pyperf_bench_3_8_gcc_9_2.json |
pyperf_bench_3_8_clang_9.json | Change   | Significance|
+=+===+===+==+=+
| 2to3| 477 ms| 527 ms
   | 1.11x slower | Significant (t=-210.10) |
+-+---+---+--+-+
| chameleon   | 13.2 ms   | 15.9 ms
  | 1.20x slower | Significant (t=-123.35) |
+-+---+---+--+-+
| chaos   | 155 ms| 193 ms
   | 1.25x slower | Significant (t=-176.57) |
+-+---+---+--+-+
| crypto_pyaes| 158 ms| 195 ms
   | 1.24x slower | Significant (t=-81.20)  |
+-+---+---+--+-+
| deltablue   | 10.2 ms   | 12.1 ms
  | 1.19x slower | Significant (t=-50.11)  |
+-+---+---+--+-+
| django_template | 69.4 ms   | 80.9 ms
  | 1.17x slower | Significant (t=-77.25)  |
+-+---+---+--+-+
| dulwich_log | 106 ms| 113 ms
   | 1.06x slower | Significant (t=-62.12)  |
+-+---+---+--+-+
| fannkuch| 659 ms| 789 ms
   | 1.20x slower | Significant (t=-62.44)  |
+-+---+---+--+-+
| float   | 165 ms| 198 ms
   | 1.20x slower | Significant (t=-124.75) |
+-+---+---+--+-+
| genshi_text | 40.5 ms   | 46.6 ms
  | 1.15x slower | Significant (t=-111.00) |
+-+---+---+--+-+
| genshi_xml  | 87.3 ms   | 97.2 ms
  | 1.11x slower | Significant (t=-66.48)  |
+-+---+---+--+-+
| go  | 361 ms| 434 ms
   | 1.20x slower | Significant (t=-136.23) |
+-+---+---+--+-+
| hexiom  | 14.0 ms   | 16.4 ms
  | 1.17x slower | Significant (t=-103.53) |
+-+---+---+--+-+
| html5lib| 143 ms| 157 ms
   | 1.10x slower | Significant (t=-14.52)  |
+-+---+---+--+-+
| json_dumps  | 18.2 ms   | 20.8 ms
  | 1.14x slower | Significant (t=-82.67)  |
+-+---+---+--+-+
| json_loads  | 42.9 us   | 46.0 us
  | 1.07x slower | Significant (t=-42.16)  |

Re: Have you some experience / link about difference between Python builded with gcc and clang?

[Skip Montanaro via Python-list]

>
> Have you compiled it optimized (--enable-optimizations --with-lto)?
>

Nope, just ./configure. Further investigation is left as an exercise for
the reader. :-)

Skip

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

Re: Have you some experience / link about difference between Python builded with gcc and clang?

[Marco Sulla via Python-list]

Oooohhh uff, I have to install latest clang... or better, compile
it as I did for gcc. And I have to read the install docs to see if
there's some trick to optimize it... and I have to read the docs of
pyperformance too (I only used pyperf until now)...

Oh well, tomorrow :-D

On Mon, 2 Mar 2020 at 00:58, Skip Montanaro  wrote:
>>
>> Have you compiled it optimized (--enable-optimizations --with-lto)?
>
>
> Nope, just ./configure. Further investigation is left as an exercise for the 
> reader. :-)
>
> Skip
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Have you some experience / link about difference between Python builded with gcc and clang?

[Skip Montanaro via Python-list]

I didn't have clang installed. It was just "sudo apt install clang-8". From
there all I had to do was build Python from scratch twice, install
pyperformance using pip after the first build, then run it after each
build. It's not difficult. Going beyond that right now is not an itch I
need to scratch though. I have other things on my plate.

Skip

On Sun, Mar 1, 2020, 6:11 PM Marco Sulla <
mail.python@marco.sulla.e4ward.com> wrote:

> Oooohhh uff, I have to install latest clang... or better, compile
> it as I did for gcc. And I have to read the install docs to see if
> there's some trick to optimize it... and I have to read the docs of
> pyperformance too (I only used pyperf until now)...
>
> Oh well, tomorrow :-D
>
> On Mon, 2 Mar 2020 at 00:58, Skip Montanaro 
> wrote:
> >>
> >> Have you compiled it optimized (--enable-optimizations --with-lto)?
> >
> >
> > Nope, just ./configure. Further investigation is left as an exercise for
> the reader. :-)
> >
> > Skip
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Have you some experience / link about difference between Python builded with gcc and clang?

[Marco Sulla via Python-list]

Good! Have you compiled it optimized (--enable-optimizations --with-lto)?

On Sun, 1 Mar 2020 at 23:48, Skip Montanaro  wrote:
>
> > As title. Currently I'm using gcc 9.2.0 and its compilation seems to
> > work well and fast. But I would know by your experience if clang can
> > produce, on a *nix system, a "faster Python".
>
> I took a quick run at this as I was wanting to give pyperformance a try. 
> Comparing GCC 9 with CLANG 8 on my Ubuntu laptop here's what I got. It seems 
> that GCC was a bit faster than CLANG pretty much across the board.
>
> +-+-+---+
> | Benchmark   | gcc | clang |
> +=+=+===+
> | 2to3| 403 ms  | 440 ms: 1.09x slower (+9%)|
> +-+-+---+
> | chameleon   | 12.6 ms | 13.5 ms: 1.07x slower (+7%)   |
> +-+-+---+
> | chaos   | 148 ms  | 169 ms: 1.14x slower (+14%)   |
> +-+-+---+
> | crypto_pyaes| 145 ms  | 157 ms: 1.08x slower (+8%)|
> +-+-+---+
> | deltablue   | 9.79 ms | 11.4 ms: 1.17x slower (+17%)  |
> +-+-+---+
> | django_template | 69.9 ms | 77.6 ms: 1.11x slower (+11%)  |
> +-+-+---+
> | dulwich_log | 89.3 ms | 92.6 ms: 1.04x slower (+4%)   |
> +-+-+---+
> | fannkuch| 590 ms  | 602 ms: 1.02x slower (+2%)|
> +-+-+---+
> | float   | 150 ms  | 160 ms: 1.07x slower (+7%)|
> +-+-+---+
> | genshi_text | 35.9 ms | 39.4 ms: 1.10x slower (+10%)  |
> +-+-+---+
> | genshi_xml  | 74.8 ms | 81.8 ms: 1.09x slower (+9%)   |
> +-+-+---+
> | go  | 339 ms  | 390 ms: 1.15x slower (+15%)   |
> +-+-+---+
> | hexiom  | 12.9 ms | 14.3 ms: 1.11x slower (+11%)  |
> +-+-+---+
> | json_dumps  | 16.4 ms | 17.6 ms: 1.07x slower (+7%)   |
> +-+-+---+
> | json_loads  | 32.9 us | 34.6 us: 1.05x slower (+5%)   |
> +-+-+---+
> | logging_format  | 13.9 us | 15.2 us: 1.09x slower (+9%)   |
> +-+-+---+
> | logging_silent  | 253 ns  | 298 ns: 1.18x slower (+18%)   |
> +-+-+---+
> | logging_simple  | 12.6 us | 14.1 us: 1.12x slower (+12%)  |
> +-+-+---+
> | mako| 21.8 ms | 24.2 ms: 1.11x slower (+11%)  |
> +-+-+---+
> | meteor_contest  | 128 ms  | 133 ms: 1.04x slower (+4%)|
> +-+-+---+
> | nbody   | 181 ms  | 190 ms: 1.05x slower (+5%)|
> +-+-+---+
> | nqueens | 128 ms  | 135 ms: 1.05x slower (+5%)|
> +-+-+---+
> | pathlib | 26.3 ms | 27.1 ms: 1.03x slower (+3%)   |
> +-+-+---+
> | pickle  | 13.3 us | 13.5 us: 1.01x slower (+1%)   |
> +-+-+---+
> | pickle_dict | 33.8 us | 33.6 us: 1.01x faster (-1%)   |
> +-+-+---+
> | pickle_list | 4.82 us | 5.18 us: 1.07x slower (+7%)   |
> +-+-+---+
> | pickle_pure_python  | 613 us  | 725 us: 1.18x slower (+18%)   |
> +-+-+---+
> | pidigits| 210 ms  | 218 ms: 1.04x slower (+4%)|
> +-+-+---+
> | pyflate | 871 ms  | 1.00 sec: 1.15x slower (+15%) |
> +-+-+---+
> | python_startup  | 10.3 ms | 10.4 ms: 

Re: Have you some experience / link about difference between Python builded with gcc and clang?

[Skip Montanaro]

> As title. Currently I'm using gcc 9.2.0 and its compilation seems to
> work well and fast. But I would know by your experience if clang can
> produce, on a *nix system, a "faster Python".

I took a quick run at this as I was wanting to give pyperformance
 a try. Comparing GCC 9 with CLANG 8 on
my Ubuntu laptop here's what I got. It seems that GCC was a bit faster than
CLANG pretty much across the board.

+-+-+---+
| Benchmark   | gcc | clang |
+=+=+===+
| 2to3| 403 ms  | 440 ms: 1.09x slower (+9%)|
+-+-+---+
| chameleon   | 12.6 ms | 13.5 ms: 1.07x slower (+7%)   |
+-+-+---+
| chaos   | 148 ms  | 169 ms: 1.14x slower (+14%)   |
+-+-+---+
| crypto_pyaes| 145 ms  | 157 ms: 1.08x slower (+8%)|
+-+-+---+
| deltablue   | 9.79 ms | 11.4 ms: 1.17x slower (+17%)  |
+-+-+---+
| django_template | 69.9 ms | 77.6 ms: 1.11x slower (+11%)  |
+-+-+---+
| dulwich_log | 89.3 ms | 92.6 ms: 1.04x slower (+4%)   |
+-+-+---+
| fannkuch| 590 ms  | 602 ms: 1.02x slower (+2%)|
+-+-+---+
| float   | 150 ms  | 160 ms: 1.07x slower (+7%)|
+-+-+---+
| genshi_text | 35.9 ms | 39.4 ms: 1.10x slower (+10%)  |
+-+-+---+
| genshi_xml  | 74.8 ms | 81.8 ms: 1.09x slower (+9%)   |
+-+-+---+
| go  | 339 ms  | 390 ms: 1.15x slower (+15%)   |
+-+-+---+
| hexiom  | 12.9 ms | 14.3 ms: 1.11x slower (+11%)  |
+-+-+---+
| json_dumps  | 16.4 ms | 17.6 ms: 1.07x slower (+7%)   |
+-+-+---+
| json_loads  | 32.9 us | 34.6 us: 1.05x slower (+5%)   |
+-+-+---+
| logging_format  | 13.9 us | 15.2 us: 1.09x slower (+9%)   |
+-+-+---+
| logging_silent  | 253 ns  | 298 ns: 1.18x slower (+18%)   |
+-+-+---+
| logging_simple  | 12.6 us | 14.1 us: 1.12x slower (+12%)  |
+-+-+---+
| mako| 21.8 ms | 24.2 ms: 1.11x slower (+11%)  |
+-+-+---+
| meteor_contest  | 128 ms  | 133 ms: 1.04x slower (+4%)|
+-+-+---+
| nbody   | 181 ms  | 190 ms: 1.05x slower (+5%)|
+-+-+---+
| nqueens | 128 ms  | 135 ms: 1.05x slower (+5%)|
+-+-+---+
| pathlib | 26.3 ms | 27.1 ms: 1.03x slower (+3%)   |
+-+-+---+
| pickle  | 13.3 us | 13.5 us: 1.01x slower (+1%)   |
+-+-+---+
| pickle_dict | 33.8 us | 33.6 us: 1.01x faster (-1%)   |
+-+-+---+
| pickle_list | 4.82 us | 5.18 us: 1.07x slower (+7%)   |
+-+-+---+
| pickle_pure_python  | 613 us  | 725 us: 1.18x slower (+18%)   |
+-+-+---+
| pidigits| 210 ms  | 218 ms: 1.04x slower (+4%)|
+-+-+---+
| pyflate | 871 ms  | 1.00 sec: 1.15x slower (+15%) |
+-+-+---+
| python_startup  | 10.3 ms | 10.4 ms: 1.01x slower (+1%)   |
+-+-+---+
| python_startup_no_site  | 7.16 ms | 7.39 ms: 1.03x slower (+3%)   |
+-+-+---+

Have you some experience / link about difference between Python builded with gcc and clang?

[Marco Sulla via Python-list]

As title. Currently I'm using gcc 9.2.0 and its compilation seems to
work well and fast. But I would know by your experience if clang can
produce, on a *nix system, a "faster Python".
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Difference between os.path.isdir and Path.is_dir

[Kirill Balunov]

Yeah it is True, for the last two weeks or so I can access bugs.python.org
in normal way. But I totally agree with the site that the best description
of this situation is "Yet".

with kind regards,
-gdg

сб, 14 дек. 2019 г. в 19:46, Terry Reedy :

> On 7/26/2019 3:12 AM, Kirill Balunov wrote:
> > чт, 25 июл. 2019 г. в 20:28, eryk sun :
> >
> >> On 7/25/19, Kirill Balunov  wrote:
> >>>
> >> import os
> >> from pathlib import Path
> >> dummy = " "   # or "" or " "
> >> os.path.isdir(dummy)
> >>> False
> >> Path(dummy).is_dir()
> >>> True
> >>
> >> I can't reproduce the above result in either Linux or Windows. The
> >> results should only be different for an empty path string, since
> >> Path('') is the same as Path('.'). The results should be the same for
> >> Path(" "), depending on whether a directory named " " exists (normally
> >> not allowed in Windows, but Linux allows it).
> >>
> >>
> > I need to confirm that it was my fault and for non-empty strings (`" "`
> or `"
> > "`), both `os.path.isdir(...)` and `Path(...).is_dir()` produce the same
> > results.So sorry for the noise.
> >
> > Concerning the case with empty path string, I will open a ticket at the
> bug
> > tracker (but for some reason it is blocked in my country :(
> > https://isitblockedinrussia.com/?host=https%3A%2F%2Fbugs.python.org%2F).
>
> For me, this now returns 'No, https://bugs.python.org is probably not
> blocked in Russia. Yet.'.
>
> > Obviously
> > these are not equivalent forms, so either this should be noted in the
> > documentation or corrected in the code.
>
> --
> Terry Jan Reedy
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Difference between os.path.isdir and Path.is_dir

[Terry Reedy]

On 7/26/2019 3:12 AM, Kirill Balunov wrote:

чт, 25 июл. 2019 г. в 20:28, eryk sun :


On 7/25/19, Kirill Balunov  wrote:



import os
from pathlib import Path
dummy = " "   # or "" or " "
os.path.isdir(dummy)

False

Path(dummy).is_dir()

True


I can't reproduce the above result in either Linux or Windows. The
results should only be different for an empty path string, since
Path('') is the same as Path('.'). The results should be the same for
Path(" "), depending on whether a directory named " " exists (normally
not allowed in Windows, but Linux allows it).



I need to confirm that it was my fault and for non-empty strings (`" "` or `"
"`), both `os.path.isdir(...)` and `Path(...).is_dir()` produce the same
results.So sorry for the noise.

Concerning the case with empty path string, I will open a ticket at the bug
tracker (but for some reason it is blocked in my country :(
https://isitblockedinrussia.com/?host=https%3A%2F%2Fbugs.python.org%2F).


For me, this now returns 'No, https://bugs.python.org is probably not 
blocked in Russia. Yet.'.



Obviously
these are not equivalent forms, so either this should be noted in the
documentation or corrected in the code.


--
Terry Jan Reedy


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

Re: What's the difference between running a script under command box and interpreter?

[jfong]

Grant Edwards於 2019年11月5日星期二 UTC+8上午12時41分24秒寫道：
> On 2019-11-04, Dennis Lee Bieber  wrote:
> > Using
> >
> >from module import *
> >
> > is often the worst thing one can do.
> 
> I agree 100%.
> 
> Unfortunately, most of the official standard library documentation is
> written assuming you do _exactly_that_.
> 
> Though it makes the documetnation more succinct, I think it encourages
> bad behavior and causes a lot of problems.
> 
> -- 
> Grant Edwards   grant.b.edwardsYow! I wonder if I could
>   at   ever get started in the
>   gmail.comcredit world?


I don't use this phrase in my files, but sometime I use it under REPL. 

I don't think it's bad showing in the document, at least it will teach someone 
who was bitten by this phrase something unique in Python:-)

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

Re: What's the difference between running a script under command box and interpreter?

[MRAB]

On 2019-11-04 21:05, Peter J. Holzer wrote:

On 2019-11-03 16:34:39 -0800, jf...@ms4.hinet.net wrote:

I innocently thought that when import module through "from test import
*", I am working on test's globals under REPL. I didn't noticed the
REPL has its own globals.


Well, you imported every global from test. So you are (kind of) working
on those globals, or at least the objects they are referencing.

In the real world, when you import a car from Germany, the car is now in
your country, but you are not in Germany. Even if you import all the
cars from Germany, you are still not in Germany.

It's the same way in Python.

Well, kind of. One important difference is that when you import a car
from Germany, that car is no longer in Germany. But when you import a
symbol from a Python module, that symbol still exists in that module.
You just have a second symbol in your namespace referencing the same
object (as Cameron pointed out).

The car itself isn't in Germany or your own country, it's just 
"somewhere". All you've imported is a (copy of a) reference to that car, 
under some name, and there can be other references to it in other places 
too, possibly under the same name, possibly under a different name.

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

Re: What's the difference between running a script under command box and interpreter?

[Peter J. Holzer]

On 2019-11-03 16:34:39 -0800, jf...@ms4.hinet.net wrote:
> I innocently thought that when import module through "from test import
> *", I am working on test's globals under REPL. I didn't noticed the
> REPL has its own globals.

Well, you imported every global from test. So you are (kind of) working
on those globals, or at least the objects they are referencing.

In the real world, when you import a car from Germany, the car is now in
your country, but you are not in Germany. Even if you import all the
cars from Germany, you are still not in Germany.

It's the same way in Python.

Well, kind of. One important difference is that when you import a car
from Germany, that car is no longer in Germany. But when you import a
symbol from a Python module, that symbol still exists in that module.
You just have a second symbol in your namespace referencing the same
object (as Cameron pointed out).

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: What's the difference between running a script under command box and interpreter?

[Grant Edwards]

On 2019-11-04, Dennis Lee Bieber  wrote:
> Using
>
>from module import *
>
> is often the worst thing one can do.

I agree 100%.

Unfortunately, most of the official standard library documentation is
written assuming you do _exactly_that_.

Though it makes the documetnation more succinct, I think it encourages
bad behavior and causes a lot of problems.

-- 
Grant Edwards   grant.b.edwardsYow! I wonder if I could
  at   ever get started in the
  gmail.comcredit world?

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

Re: What's the difference between running a script under command box and interpreter?

[Chris Angelico]

On Mon, Nov 4, 2019 at 3:16 PM  wrote:
>
> Chris Angelico於 2019年11月4日星期一 UTC+8上午10時19分50秒寫道：
> > On Mon, Nov 4, 2019 at 1:01 PM  wrote:
> > >
> > > Chris Angelico於 2019年11月4日星期一 UTC+8上午8時43分07秒寫道：
> > > > Ah, that's a fair point. If you specifically WANT that behaviour, what
> > > > you can do is invoke the script interactively:
> > > >
> > > > python3 -i test.py
> > > >
> > > > That'll run the script as normal, and then drop you into the REPL. All
> > > > your interactive globals *are* that module's globals.
> > > >
> > > > ChrisA
> > >
> > > It surprises me that REPL has essential different behavior in these two 
> > > situations.
> > >
> >
> > Not really. In each case, the REPL lets you interactively execute code
> > as part of a module. If you start with "-i somescript.py", it starts
> > out by running the contents of that script; otherwise, you start with
> > nothing (as if you ran "-i empty-file.py"). The REPL does the same
> > thing every time; it's a difference between creating the functions
> > directly and importing them.
> >
> > ChrisA
>
> I mean, taking this simple example:
> ---test.py---
> def main():
> print(rule)
> if __name__ == '__main__:
> rule = 1
> main()
> ---
>
> case 1:
> py -i test.py
> 1
> >>> globals()
> >>> main.__globals__
>
> case 2:
> py
> >>> from test import *
> >>> globals()
> >>> main.__globals__
>
> The result is much different. In case 1, the REPL and the module seems in the 
> same global space:-)
>

Yes. The difference is that one of them uses "import" and the other does not.

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

Re: What's the difference between running a script under command box and interpreter?

[jfong]

Chris Angelico於 2019年11月4日星期一 UTC+8上午10時19分50秒寫道：
> On Mon, Nov 4, 2019 at 1:01 PM  wrote:
> >
> > Chris Angelico於 2019年11月4日星期一 UTC+8上午8時43分07秒寫道：
> > > Ah, that's a fair point. If you specifically WANT that behaviour, what
> > > you can do is invoke the script interactively:
> > >
> > > python3 -i test.py
> > >
> > > That'll run the script as normal, and then drop you into the REPL. All
> > > your interactive globals *are* that module's globals.
> > >
> > > ChrisA
> >
> > It surprises me that REPL has essential different behavior in these two 
> > situations.
> >
> 
> Not really. In each case, the REPL lets you interactively execute code
> as part of a module. If you start with "-i somescript.py", it starts
> out by running the contents of that script; otherwise, you start with
> nothing (as if you ran "-i empty-file.py"). The REPL does the same
> thing every time; it's a difference between creating the functions
> directly and importing them.
> 
> ChrisA

I mean, taking this simple example:
---test.py---
def main():
print(rule)
if __name__ == '__main__:
rule = 1
main()
---

case 1:
py -i test.py
1
>>> globals()
>>> main.__globals__

case 2:
py
>>> from test import *
>>> globals()
>>> main.__globals__

The result is much different. In case 1, the REPL and the module seems in the 
same global space:-)

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

Re: What's the difference between running a script under command box and interpreter?

[Chris Angelico]

On Mon, Nov 4, 2019 at 1:01 PM  wrote:
>
> Chris Angelico於 2019年11月4日星期一 UTC+8上午8時43分07秒寫道：
> > Ah, that's a fair point. If you specifically WANT that behaviour, what
> > you can do is invoke the script interactively:
> >
> > python3 -i test.py
> >
> > That'll run the script as normal, and then drop you into the REPL. All
> > your interactive globals *are* that module's globals.
> >
> > ChrisA
>
> It surprises me that REPL has essential different behavior in these two 
> situations.
>

Not really. In each case, the REPL lets you interactively execute code
as part of a module. If you start with "-i somescript.py", it starts
out by running the contents of that script; otherwise, you start with
nothing (as if you ran "-i empty-file.py"). The REPL does the same
thing every time; it's a difference between creating the functions
directly and importing them.

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

Re: What's the difference between running a script under command box and interpreter?

[jfong]

Chris Angelico於 2019年11月4日星期一 UTC+8上午8時43分07秒寫道：
> On Mon, Nov 4, 2019 at 11:36 AM  wrote:
> >
> > Peter J. Holzer於 2019年11月4日星期一 UTC+8上午3時59分36秒寫道：
> > > On 2019-11-01 04:24:38 -0700, jf...@ms4.hinet.net wrote:
> > > > > The globals are your current module's namespace, and functions defines
> > > > > in a module are bound to that module's namespace.
> > > > >
> > > > > Strip your test.py back. A lot. Try this:
> > > > >
> > > > > def main():
> > > > >   print(rule)
> > > > >
> > > > > Now, let's use that:
> > > > >
> > > > > Python 3.7.4 (default, Sep 28 2019, 13:34:38)
> > > > > [Clang 8.0.0 (clang-800.0.42.1)] on darwin
> > > > > Type "help", "copyright", "credits" or "license" for more 
> > > > > information.
> > > > > >>> import test
> > > > > >>> test.main()
> > > > > Traceback (most recent call last):
> > > > >   File "", line 1, in 
> > > > >   File "/Users/cameron/tmp/d1/test.py", line 2, in main
> > > > > print(rule)
> > > > > NameError: name 'rule' is not defined
> > >
> > > [Explanation snipped]
> > >
> > > > I didn't noticed that the interpreter has its own globals. Thanks for 
> > > > reminding.
> > >
> > > It's not really "the interpreter" (I think you mean the REPL) which has
> > > it's own globals. Every module/file has its own globals.
> > >
> > > The same thing happens non-interactively:
> > >
> > > % cat test.py
> > > def main():
> > > print(rule)
> > >
> > > % cat foo.py
> > > #!/usr/bin/python3
> > >
> > > from test import *
> > >
> > > rule = 42
> > > main()
> > >
> > > % ./foo.py
> > > Traceback (most recent call last):
> > >   File "./foo.py", line 6, in 
> > > main()
> > >   File "/home/hjp/tmp/test.py", line 2, in main
> > > print(rule)
> > > NameError: name 'rule' is not defined
> > >
> > > The "rule" identifier in main() refers to a "rule" variable in the
> > > module test. If you set a variable "rule" somewhere else (in foo.py or
> > > the REPL, ...), that has no effect. How should python know that you want
> > > to set the rule variable in the test module?
> > >
> > >   hp
> > >
> > > --
> > >_  | Peter J. Holzer| Story must make more sense than reality.
> > > |_|_) ||
> > > | |   | h...@hjp.at |-- Charles Stross, "Creative writing
> > > __/   | http://www.hjp.at/ |   challenge!"
> >
> >
> > I innocently thought that when import module through "from test import *", 
> > I am working on test's globals under REPL. I didn't noticed the REPL has 
> > its own globals.
> >
> 
> Ah, that's a fair point. If you specifically WANT that behaviour, what
> you can do is invoke the script interactively:
> 
> python3 -i test.py
> 
> That'll run the script as normal, and then drop you into the REPL. All
> your interactive globals *are* that module's globals.
> 
> ChrisA

It surprises me that REPL has essential different behavior in these two 
situations.

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

Re: What's the difference between running a script under command box and interpreter?

[Cameron Simpson]

On 03Nov2019 16:34, Jach Fong  wrote:

Peter J. Holzer於 2019年11月4日星期一 UTC+8上午3時59分36秒寫道：
It's not really "the interpreter" (I think you mean the REPL) which 
has

it's own globals. Every module/file has its own globals.

The same thing happens non-interactively:

% cat test.py
def main():
print(rule)

% cat foo.py
#!/usr/bin/python3

from test import *

rule = 42
main()

% ./foo.py
Traceback (most recent call last):
  File "./foo.py", line 6, in 
main()
  File "/home/hjp/tmp/test.py", line 2, in main
print(rule)
NameError: name 'rule' is not defined

The "rule" identifier in main() refers to a "rule" variable in the
module test. If you set a variable "rule" somewhere else (in foo.py or
the REPL, ...), that has no effect. How should python know that you want
to set the rule variable in the test module? [...]


I innocently thought that when import module through "from test import *", I am 
working on test's globals under REPL. I didn't noticed the REPL has its own globals.


Aye. An import statement is essentially a funny shaped assignment 
statement (aside from the side effect of loading the required module).


When you go:

 from blah import foo

You're getting a _local_ variable "foo" which references the same 
_value_ that "blah.foo" also references. But it is independent of 
"blah.foo"; assigning to it (changing what it references) does not 
change what "blah.foo" references.


To take a concrete example, I've a tiny module "cs.x" which essentially 
supplies just a single function X() whose purpose it to write a debug 
message (no logging modules or other complications). So lots of my dev 
code has (while debugging):


   from cs.x import X

and then:

   X("some message about %s", variable_name)

X() normally just writes to sys.stderr, but it has some module level 
mode switches such X_via_tty which literally opens "/dev/tty" and writes 
to that, invented for situations where sys.stderr has been intercepted.


Occasionally I need to set that mode (usually in a unit test I'm 
debugging). So I go:


   from cs.x import X  # as normal
   import cs.x; cs.x.X_via_tty = True

If I went:

   from cs.x import X, X_via_tty
   X_via_tty = True

it wouldn't work.


How should python know that you want to set the rule variable in the test 
module?


My 'wrong' answer will be, at the time I raised my question, that when 
import two different modules either has 'rule' variable, REPL will see 
the second imported one. No kidding:-)


Well:

   from mod1 import rule
   from mod2 import rule

is like:

   import mod1
   import mod2
   rule = mod1.rule# copy reference
   rule = mod2.rule# copy the other reference

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: What's the difference between running a script under command box and interpreter?

[Chris Angelico]

On Mon, Nov 4, 2019 at 11:36 AM  wrote:
>
> Peter J. Holzer於 2019年11月4日星期一 UTC+8上午3時59分36秒寫道：
> > On 2019-11-01 04:24:38 -0700, jf...@ms4.hinet.net wrote:
> > > > The globals are your current module's namespace, and functions defines
> > > > in a module are bound to that module's namespace.
> > > >
> > > > Strip your test.py back. A lot. Try this:
> > > >
> > > > def main():
> > > >   print(rule)
> > > >
> > > > Now, let's use that:
> > > >
> > > > Python 3.7.4 (default, Sep 28 2019, 13:34:38)
> > > > [Clang 8.0.0 (clang-800.0.42.1)] on darwin
> > > > Type "help", "copyright", "credits" or "license" for more 
> > > > information.
> > > > >>> import test
> > > > >>> test.main()
> > > > Traceback (most recent call last):
> > > >   File "", line 1, in 
> > > >   File "/Users/cameron/tmp/d1/test.py", line 2, in main
> > > > print(rule)
> > > > NameError: name 'rule' is not defined
> >
> > [Explanation snipped]
> >
> > > I didn't noticed that the interpreter has its own globals. Thanks for 
> > > reminding.
> >
> > It's not really "the interpreter" (I think you mean the REPL) which has
> > it's own globals. Every module/file has its own globals.
> >
> > The same thing happens non-interactively:
> >
> > % cat test.py
> > def main():
> > print(rule)
> >
> > % cat foo.py
> > #!/usr/bin/python3
> >
> > from test import *
> >
> > rule = 42
> > main()
> >
> > % ./foo.py
> > Traceback (most recent call last):
> >   File "./foo.py", line 6, in 
> > main()
> >   File "/home/hjp/tmp/test.py", line 2, in main
> > print(rule)
> > NameError: name 'rule' is not defined
> >
> > The "rule" identifier in main() refers to a "rule" variable in the
> > module test. If you set a variable "rule" somewhere else (in foo.py or
> > the REPL, ...), that has no effect. How should python know that you want
> > to set the rule variable in the test module?
> >
> >   hp
> >
> > --
> >_  | Peter J. Holzer| Story must make more sense than reality.
> > |_|_) ||
> > | |   | h...@hjp.at |-- Charles Stross, "Creative writing
> > __/   | http://www.hjp.at/ |   challenge!"
>
>
> I innocently thought that when import module through "from test import *", I 
> am working on test's globals under REPL. I didn't noticed the REPL has its 
> own globals.
>

Ah, that's a fair point. If you specifically WANT that behaviour, what
you can do is invoke the script interactively:

python3 -i test.py

That'll run the script as normal, and then drop you into the REPL. All
your interactive globals *are* that module's globals.

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

Re: What's the difference between running a script under command box and interpreter?

[jfong]

Peter J. Holzer於 2019年11月4日星期一 UTC+8上午3時59分36秒寫道：
> On 2019-11-01 04:24:38 -0700, jf...@ms4.hinet.net wrote:
> > > The globals are your current module's namespace, and functions defines 
> > > in a module are bound to that module's namespace.
> > > 
> > > Strip your test.py back. A lot. Try this:
> > > 
> > > def main():
> > >   print(rule)
> > > 
> > > Now, let's use that:
> > > 
> > > Python 3.7.4 (default, Sep 28 2019, 13:34:38)
> > > [Clang 8.0.0 (clang-800.0.42.1)] on darwin
> > > Type "help", "copyright", "credits" or "license" for more information.
> > > >>> import test
> > > >>> test.main()
> > > Traceback (most recent call last):
> > >   File "", line 1, in 
> > >   File "/Users/cameron/tmp/d1/test.py", line 2, in main
> > > print(rule)
> > > NameError: name 'rule' is not defined
> 
> [Explanation snipped]
> 
> > I didn't noticed that the interpreter has its own globals. Thanks for 
> > reminding.
> 
> It's not really "the interpreter" (I think you mean the REPL) which has
> it's own globals. Every module/file has its own globals.
> 
> The same thing happens non-interactively:
> 
> % cat test.py 
> def main():
> print(rule)
> 
> % cat foo.py 
> #!/usr/bin/python3
> 
> from test import *
> 
> rule = 42
> main()
> 
> % ./foo.py 
> Traceback (most recent call last):
>   File "./foo.py", line 6, in 
> main()
>   File "/home/hjp/tmp/test.py", line 2, in main
> print(rule)
> NameError: name 'rule' is not defined
> 
> The "rule" identifier in main() refers to a "rule" variable in the
> module test. If you set a variable "rule" somewhere else (in foo.py or
> the REPL, ...), that has no effect. How should python know that you want
> to set the rule variable in the test module?
> 
>   hp
> 
> -- 
>_  | Peter J. Holzer| Story must make more sense than reality.
> |_|_) ||
> | |   | h...@hjp.at |-- Charles Stross, "Creative writing
> __/   | http://www.hjp.at/ |   challenge!"


I innocently thought that when import module through "from test import *", I am 
working on test's globals under REPL. I didn't noticed the REPL has its own 
globals.

>>> How should python know that you want to set the rule variable in the test 
>>> module?

My 'wrong' answer will be, at the time I raised my question, that when import 
two different modules either has 'rule' variable, REPL will see the second 
imported one. No kidding:-) 

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

Re: What's the difference between running a script under command box and interpreter?

[Peter J. Holzer]

On 2019-11-01 04:24:38 -0700, jf...@ms4.hinet.net wrote:
> > The globals are your current module's namespace, and functions defines 
> > in a module are bound to that module's namespace.
> > 
> > Strip your test.py back. A lot. Try this:
> > 
> > def main():
> >   print(rule)
> > 
> > Now, let's use that:
> > 
> > Python 3.7.4 (default, Sep 28 2019, 13:34:38)
> > [Clang 8.0.0 (clang-800.0.42.1)] on darwin
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> import test
> > >>> test.main()
> > Traceback (most recent call last):
> >   File "", line 1, in 
> >   File "/Users/cameron/tmp/d1/test.py", line 2, in main
> > print(rule)
> > NameError: name 'rule' is not defined

[Explanation snipped]

> I didn't noticed that the interpreter has its own globals. Thanks for 
> reminding.

It's not really "the interpreter" (I think you mean the REPL) which has
it's own globals. Every module/file has its own globals.

The same thing happens non-interactively:

% cat test.py 
def main():
print(rule)

% cat foo.py 
#!/usr/bin/python3

from test import *

rule = 42
main()

% ./foo.py 
Traceback (most recent call last):
  File "./foo.py", line 6, in 
main()
  File "/home/hjp/tmp/test.py", line 2, in main
print(rule)
NameError: name 'rule' is not defined

The "rule" identifier in main() refers to a "rule" variable in the
module test. If you set a variable "rule" somewhere else (in foo.py or
the REPL, ...), that has no effect. How should python know that you want
to set the rule variable in the test module?

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: What's the difference between running a script under command box and interpreter?

[jfong]

Cameron Simpson於 2019年11月1日星期五 UTC+8下午5時28分42秒寫道：
> On 31Oct2019 22:03, Jach Fong  wrote:
> >Cameron Simpson於 2019年11月1日星期五 UTC+8下午12時13分45秒寫道：
> >> On 31Oct2019 20:44, Jach Fong  wrote:
> >> >The script test.py is something like this:
> >> >---test.py
> >> >from pyeds import fsm
> >> >...
> >> >class Rule_Parse:
> >> >def __init__(self):
> >> >...
> >> >self.current_char = ''
> >> >...
> >> >def main(input_str):
> >> >for c in input_str:
> >> >...
> >> >rule.current_char = c
> >> >...
> >> >
> >> >if __name__ == '__main__':
> >> >input_str = '(NNS(acoustics) & RB(not)) | JJ(muted)'
> >> >rule = Rule_Parse()
> >> >main(input_str)
> >> >...
> >> >
> >> >---
> >> >The test.py can run correctly under command box:
> >> >D:\Works\Python\pyeds-master\src>py test.py
> >> >
> >> >but fails when running under interpreter:
> >> >D:\Works\Python\pyeds-master\src>py
> >> >Python 3.4.4 (v3.4.4:737efcadf5a6, Dec 20 2015, 19:28:18) [MSC v.1600 32 
> >> >bit (Intel)] on win32
> >> >Type "help", "copyright", "credits" or "license" for more information.
> >>  from test import *
> >>  input_str = "(NNS(acoustics) & RB(not)) | JJ(muted)"
> >>  rule = Rule_Parse()
> >>  main(input_str)
> >> >Traceback (most recent call last):
> >> >  File "", line 1, in 
> >> >  File "D:\Works\Python\pyeds-master\src\test.py", line 229, in main
> >> >rule.current_char = c
> >> >NameError: name 'rule' is not defined
> >> 
> >> >
> >> >I did check the globals using dir() and the 'rule' is there, no doubt.
> >>
> >> It matters how you checked this. This isn't apparent.
> [...]
> >Yes, the 'if' body is not executed when I import test.py under 
> >interpreter, that's why I manually execute them there.
> >What puzzles me is that the globals() has a 'rule' object in both 
> >cases. Why this one doesn't work?
> 
> I think I have misinterpreted what you've done.
> 
> The globals are your current module's namespace, and functions defines 
> in a module are bound to that module's namespace.
> 
> Strip your test.py back. A lot. Try this:
> 
> def main():
>   print(rule)
> 
> Now, let's use that:
> 
> Python 3.7.4 (default, Sep 28 2019, 13:34:38)
> [Clang 8.0.0 (clang-800.0.42.1)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import test
> >>> test.main()
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/Users/cameron/tmp/d1/test.py", line 2, in main
> print(rule)
> NameError: name 'rule' is not defined
> 
> What's happening here?
> 
> When we call main it tries to print "rule" from its module's globals.  
> 
> The first time you call it that doesn't exist, and we get your error.
> 
> Setting rule=1 in the interpreter's space doesn't help (the stuff below 
> if from the same session continued from above):
> 
> >>> rule=1
> >>> test.main()
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/Users/cameron/tmp/d1/test.py", line 2, in main
> print(rule)
> NameError: name 'rule' is not defined
> 
> But if we define rule in the "test" module things improve:
> 
> >>> test.rule=2
> >>> test.main()
> 2
> 
> Importing main from test doesn't change where it looks for its globals:
> 
> >>> from test import main as my_main
> >>> my_main()
> 2
> 
> That value (2) is still coming out of the test module.
> 
> Cheers,
> Cameron Simpson 

I didn't noticed that the interpreter has its own globals. Thanks for reminding.

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

Re: What's the difference between running a script under command box and interpreter?

[Cameron Simpson]

On 31Oct2019 22:03, Jach Fong  wrote:

Cameron Simpson於 2019年11月1日星期五 UTC+8下午12時13分45秒寫道：

On 31Oct2019 20:44, Jach Fong  wrote:
>The script test.py is something like this:
>---test.py
>from pyeds import fsm
>...
>class Rule_Parse:
>def __init__(self):
>...
>self.current_char = ''
>...
>def main(input_str):
>for c in input_str:
>...
>rule.current_char = c
>...
>
>if __name__ == '__main__':
>input_str = '(NNS(acoustics) & RB(not)) | JJ(muted)'
>rule = Rule_Parse()
>main(input_str)
>...
>
>---
>The test.py can run correctly under command box:
>D:\Works\Python\pyeds-master\src>py test.py
>
>but fails when running under interpreter:
>D:\Works\Python\pyeds-master\src>py
>Python 3.4.4 (v3.4.4:737efcadf5a6, Dec 20 2015, 19:28:18) [MSC v.1600 32 bit 
(Intel)] on win32
>Type "help", "copyright", "credits" or "license" for more information.
 from test import *
 input_str = "(NNS(acoustics) & RB(not)) | JJ(muted)"
 rule = Rule_Parse()
 main(input_str)
>Traceback (most recent call last):
>  File "", line 1, in 
>  File "D:\Works\Python\pyeds-master\src\test.py", line 229, in main
>rule.current_char = c
>NameError: name 'rule' is not defined

>
>I did check the globals using dir() and the 'rule' is there, no doubt.

It matters how you checked this. This isn't apparent.

[...]
Yes, the 'if' body is not executed when I import test.py under 
interpreter, that's why I manually execute them there.
What puzzles me is that the globals() has a 'rule' object in both 
cases. Why this one doesn't work?


I think I have misinterpreted what you've done.

The globals are your current module's namespace, and functions defines 
in a module are bound to that module's namespace.


Strip your test.py back. A lot. Try this:

   def main():
 print(rule)

Now, let's use that:

   Python 3.7.4 (default, Sep 28 2019, 13:34:38)
   [Clang 8.0.0 (clang-800.0.42.1)] on darwin
   Type "help", "copyright", "credits" or "license" for more information.
   >>> import test
   >>> test.main()
   Traceback (most recent call last):
 File "", line 1, in 
 File "/Users/cameron/tmp/d1/test.py", line 2, in main
   print(rule)
   NameError: name 'rule' is not defined

What's happening here?

When we call main it tries to print "rule" from its module's globals.  


The first time you call it that doesn't exist, and we get your error.

Setting rule=1 in the interpreter's space doesn't help (the stuff below 
if from the same session continued from above):


   >>> rule=1
   >>> test.main()
   Traceback (most recent call last):
 File "", line 1, in 
 File "/Users/cameron/tmp/d1/test.py", line 2, in main
   print(rule)
   NameError: name 'rule' is not defined

But if we define rule in the "test" module things improve:

   >>> test.rule=2
   >>> test.main()
   2

Importing main from test doesn't change where it looks for its globals:

   >>> from test import main as my_main
   >>> my_main()
   2

That value (2) is still coming out of the test module.

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: What's the difference between running a script under command box and interpreter?

[jfong]

Cameron Simpson於 2019年11月1日星期五 UTC+8下午12時13分45秒寫道：
> On 31Oct2019 20:44, Jach Fong  wrote:
> >The script test.py is something like this:
> >---test.py
> >from pyeds import fsm
> >...
> >...
> >class Rule_Parse:
> >def __init__(self):
> >...
> >self.current_char = ''
> >...
> >...
> >def main(input_str):
> >for c in input_str:
> >...
> >rule.current_char = c
> >...
> >
> >if __name__ == '__main__':
> >input_str = '(NNS(acoustics) & RB(not)) | JJ(muted)'
> >rule = Rule_Parse()
> >main(input_str)
> >...
> >
> >---
> >The test.py can run correctly under command box:
> >D:\Works\Python\pyeds-master\src>py test.py
> >
> >but fails when running under interpreter:
> >D:\Works\Python\pyeds-master\src>py
> >Python 3.4.4 (v3.4.4:737efcadf5a6, Dec 20 2015, 19:28:18) [MSC v.1600 32 bit 
> >(Intel)] on win32
> >Type "help", "copyright", "credits" or "license" for more information.
>  from test import *
>  input_str = "(NNS(acoustics) & RB(not)) | JJ(muted)"
>  rule = Rule_Parse()
>  main(input_str)
> >Traceback (most recent call last):
> >  File "", line 1, in 
> >  File "D:\Works\Python\pyeds-master\src\test.py", line 229, in main
> >rule.current_char = c
> >NameError: name 'rule' is not defined
> 
> >
> >I did check the globals using dir() and the 'rule' is there, no doubt.
> 
> It matters how you checked this. This isn't apparent.
> 
> >I also tried "py -m pdb test.py" and step through it, no problem too.
> 
> This:
>   py test.py
> and this:
>   py -m pdb test
> 
> both run test.py with __name__ set to "__main__" to indicate that 
> test.py is the main programme.
> 
> When you "import test", the module's __name__ is from the import 
> ("test") i.e. not the main programme.
> 
> The bottom of your module has an if statement whose body only runs when 
> this is the main programme.
> 
> The core issue is that the global "rule" is _only_ defined inside that 
> if statement.
> 
> You might set it unconditionally to None at the start of the file, but 
> that would only change the failure mode.
> 
> You might set it unconditionally to Rule_Parse() at the top of the file 
> but that pointlessly instantiates an instance of Rule_Parse which might 
> never be needed (maybe that is cheap, but many other classes are not).  
> The basic intent of an import is to define various classes and other 
> names, but _not_, generally, to create class instances and do 
> significant work.
> 
> This is really an example illustrating one reason why global variables 
> are considered things to avoid almost all of the time. Had main() 
> required "rule" as a parameter then it would not have been possible to 
> call it without at least providing a rule. The same applies with most 
> other functions: if they all require their external state via parameters 
> then you can't miss things out. (You can, of course, always pass 
> incorrect values, but that is usually easier to debug.)
> 
> Avoid globals; they are usually a source of bugs.
> 
> Cheers,
> Cameron Simpson 

Yes, the 'if' body is not executed when I import test.py under interpreter, 
that's why I manually execute them there.

What puzzles me is that the globals() has a 'rule' object in both cases. Why 
this one doesn't work?

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

Re: What's the difference between running a script under command box and interpreter?

[Cameron Simpson]

On 31Oct2019 20:44, Jach Fong  wrote:

The script test.py is something like this:
---test.py
from pyeds import fsm
...
...
class Rule_Parse:
   def __init__(self):
   ...
   self.current_char = ''
...
...
def main(input_str):
   for c in input_str:
   ...
   rule.current_char = c
   ...

if __name__ == '__main__':
   input_str = '(NNS(acoustics) & RB(not)) | JJ(muted)'
   rule = Rule_Parse()
   main(input_str)
   ...

---
The test.py can run correctly under command box:
D:\Works\Python\pyeds-master\src>py test.py

but fails when running under interpreter:
D:\Works\Python\pyeds-master\src>py
Python 3.4.4 (v3.4.4:737efcadf5a6, Dec 20 2015, 19:28:18) [MSC v.1600 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.

from test import *
input_str = "(NNS(acoustics) & RB(not)) | JJ(muted)"
rule = Rule_Parse()
main(input_str)

Traceback (most recent call last):
 File "", line 1, in 
 File "D:\Works\Python\pyeds-master\src\test.py", line 229, in main
   rule.current_char = c
NameError: name 'rule' is not defined




I did check the globals using dir() and the 'rule' is there, no doubt.


It matters how you checked this. This isn't apparent.


I also tried "py -m pdb test.py" and step through it, no problem too.


This:
 py test.py
and this:
 py -m pdb test

both run test.py with __name__ set to "__main__" to indicate that 
test.py is the main programme.


When you "import test", the module's __name__ is from the import 
("test") i.e. not the main programme.


The bottom of your module has an if statement whose body only runs when 
this is the main programme.


The core issue is that the global "rule" is _only_ defined inside that 
if statement.


You might set it unconditionally to None at the start of the file, but 
that would only change the failure mode.


You might set it unconditionally to Rule_Parse() at the top of the file 
but that pointlessly instantiates an instance of Rule_Parse which might 
never be needed (maybe that is cheap, but many other classes are not).  
The basic intent of an import is to define various classes and other 
names, but _not_, generally, to create class instances and do 
significant work.


This is really an example illustrating one reason why global variables 
are considered things to avoid almost all of the time. Had main() 
required "rule" as a parameter then it would not have been possible to 
call it without at least providing a rule. The same applies with most 
other functions: if they all require their external state via parameters 
then you can't miss things out. (You can, of course, always pass 
incorrect values, but that is usually easier to debug.)


Avoid globals; they are usually a source of bugs.

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

What's the difference between running a script under command box and interpreter?

[jfong]

The script test.py is something like this:
---test.py
from pyeds import fsm
...
...
class Rule_Parse:
def __init__(self):
...
self.current_char = ''
...
...
def main(input_str):
for c in input_str:
...
rule.current_char = c
...

if __name__ == '__main__':
input_str = '(NNS(acoustics) & RB(not)) | JJ(muted)'
rule = Rule_Parse()
main(input_str)
...

---
The test.py can run correctly under command box:
D:\Works\Python\pyeds-master\src>py test.py

but fails when running under interpreter:
D:\Works\Python\pyeds-master\src>py
Python 3.4.4 (v3.4.4:737efcadf5a6, Dec 20 2015, 19:28:18) [MSC v.1600 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from test import *
>>> input_str = "(NNS(acoustics) & RB(not)) | JJ(muted)"
>>> rule = Rule_Parse()
>>> main(input_str)
Traceback (most recent call last):
  File "", line 1, in 
  File "D:\Works\Python\pyeds-master\src\test.py", line 229, in main
rule.current_char = c
NameError: name 'rule' is not defined
>>>

I did check the globals using dir() and the 'rule' is there, no doubt.
I also tried "py -m pdb test.py" and step through it, no problem too.

Why?

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

RE: What is the Difference Between quit() and exit() commands in Python?

[wesley]

  Hi

exit (http://docs.python.org/2/library/constants.html#exit; rel="noreferrer) is 
an alias for quit (or vice-versa). They exist together simply to make Python more 
user-friendly.

please refer:  
https://stackoverflow.com/questions/19747371/python-exit-commands-why-so-many-and-when-should-each-be-used
 
(https://stackoverflow.com/questions/19747371/python-exit-commands-why-so-many-and-when-should-each-be-used)



-ursprngliche Nachricht-
Von:  hongyi.z...@gmail.com (mailto:hongyi.z...@gmail.com)
Gesendet: 16.09.2019 14:35 Uhr
An:  python-list@python.org (mailto:python-list@python.org)
Betreff: What is the Difference Between quit() and exit() commands in Python?



What is the Difference Between quit() and exit() commands in Python?
--
 mail.python.org/mailman/listinfo/python-list 
(https://mail.python.org/mailman/listinfo/python-list; target="_blank" 
rel="noopener)


-ursprngliche Nachricht Ende-



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

Re: What is the Difference Between quit() and exit() commands in Python?

[Eryk Sun]

On 9/16/19, Hongyi Zhao  wrote:
>
> What is the Difference Between quit() and exit() commands in Python?

They're different instances of the Quitter class, which is available
if site.py is imported (i.e. not with the -S command-line option).
They're created by site.setquit():

def setquit():
"""Define new builtins 'quit' and 'exit'.

These are objects which make the interpreter exit when called.
The repr of each object contains a hint at how it works.

"""
if os.sep == '\\':
eof = 'Ctrl-Z plus Return'
else:
eof = 'Ctrl-D (i.e. EOF)'

builtins.quit = _sitebuiltins.Quitter('quit', eof)
builtins.exit = _sitebuiltins.Quitter('exit', eof)

exit(code) or quit(code) closes sys.stdin and raises SystemExit(code):

>>> quit.__class__


>>> print(inspect.getsource(type(quit)))
class Quitter(object):
def __init__(self, name, eof):
self.name = name
self.eof = eof
def __repr__(self):
return 'Use %s() or %s to exit' % (self.name, self.eof)
def __call__(self, code=None):
# Shells like IDLE catch the SystemExit, but listen when their
# stdin wrapper is closed.
try:
sys.stdin.close()
except:
pass
raise SystemExit(code)

For example:

>>> try:
... quit(42)
... except BaseException as e:
... print(repr(e))
...
SystemExit(42,)
>>> sys.stdin.closed
True

Alternatively, sys.exit is a builtin function that's equivalent to
`raise SystemExit(code)` but does not close sys.stdin. For example:

>>> try:
... sys.exit(42)
... except BaseException as e:
... print(repr(e))
...
SystemExit(42,)
>>> sys.stdin.closed
False
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What is the Difference Between quit() and exit() commands in Python?

[Peter Otten]

Hongyi Zhao wrote:

> What is the Difference Between quit() and exit() commands in Python?

They are instances of the same type

>>> import inspect
>>> type(quit) is type(exit)
True
>>> print(inspect.getsource(type(quit)))
class Quitter(object):
def __init__(self, name, eof):
self.name = name
self.eof = eof
def __repr__(self):
return 'Use %s() or %s to exit' % (self.name, self.eof)
def __call__(self, code=None):
# Shells like IDLE catch the SystemExit, but listen when their
# stdin wrapper is closed.
try:
sys.stdin.close()
except:
pass
raise SystemExit(code)


There is no difference, except for the name attribute and the repr() text:

>>> exit.name, exit.eof, exit
('exit', 'Ctrl-D (i.e. EOF)', Use exit() or Ctrl-D (i.e. EOF) to exit)
>>> quit.name, quit.eof, quit
('quit', 'Ctrl-D (i.e. EOF)', Use quit() or Ctrl-D (i.e. EOF) to exit)


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

What is the Difference Between quit() and exit() commands in Python?

[Hongyi Zhao]

What is the Difference Between quit() and exit() commands in Python?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Difference between os.path.isdir and Path.is_dir

[Kirill Balunov]

чт, 25 июл. 2019 г. в 20:28, eryk sun :

> On 7/25/19, Kirill Balunov  wrote:
> >
>  import os
>  from pathlib import Path
>  dummy = " "   # or "" or " "
>  os.path.isdir(dummy)
> > False
>  Path(dummy).is_dir()
> > True
>
> I can't reproduce the above result in either Linux or Windows. The
> results should only be different for an empty path string, since
> Path('') is the same as Path('.'). The results should be the same for
> Path(" "), depending on whether a directory named " " exists (normally
> not allowed in Windows, but Linux allows it).
>
>
I need to confirm that it was my fault and for non-empty strings (`" "` or `"
"`), both `os.path.isdir(...)` and `Path(...).is_dir()` produce the same
results.So sorry for the noise.

Concerning the case with empty path string, I will open a ticket at the bug
tracker (but for some reason it is blocked in my country :(
https://isitblockedinrussia.com/?host=https%3A%2F%2Fbugs.python.org%2F).
Obviously
these are not equivalent forms, so either this should be noted in the
documentation or corrected in the code.

with kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Difference between os.path.isdir and Path.is_dir

[Cameron Simpson]

On 26Jul2019 03:43, Chris Angelico  wrote:

On Fri, Jul 26, 2019 at 3:28 AM eryk sun  wrote:

On 7/25/19, Kirill Balunov  wrote:
 import os
 from pathlib import Path
 dummy = " "   # or "" or " "
 os.path.isdir(dummy)
> False
 Path(dummy).is_dir()
> True

I can't reproduce the above result in either Linux or Windows. The
results should only be different for an empty path string, since
Path('') is the same as Path('.'). The results should be the same for
Path(" "), depending on whether a directory named " " exists (normally
not allowed in Windows, but Linux allows it).


Try an empty string, no spaces. To pathlib.Path, that means the
current directory. To os.path.abspath, that means the current
directory. To os.stat, it doesn't exist.


And for some context, on older UNIXen "" did stat successfully.

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: Difference between os.path.isdir and Path.is_dir

[Cameron Simpson]

On 25Jul2019 13:40, eryk sun  wrote:

Windows trims trailing spaces and dots from the final component of a
path, unless we use a non-normalized \\?\ path.


Hoo!

Well, that explains some extremely weird NAS behaviour I encountered the 
other month with some paths ending in spaces. (My machine and I think 
also the NAS were UNIX/Linux at each end, but speaking over SMB.) 
Guessing that the NAS was doing only a half hearted implementation of 
the trailing spaces semantics.


Interesting:-)

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: Difference between os.path.isdir and Path.is_dir

[Chris Angelico]

On Fri, Jul 26, 2019 at 6:13 AM Kirill Balunov  wrote:
>
>
>
> чт, 25 июл. 2019 г. в 22:58, Chris Angelico :
>>
>> On Fri, Jul 26, 2019 at 5:52 AM Kirill Balunov  
>> wrote:
>> [...]
>> > No, it's not just because of curiosity. I will try to tell the background, 
>> > and maybe I went the wrong way initially. There is a very cool project 
>> > https://github.com/3b1b/manim, it allows you to visualize math (I don’t 
>> > know how to describe it better you can see some examples here 
>> > https://www.3blue1brown.com) and it works lovely on Linux. For some 
>> > reason, I need to use it on Windows. Problems began to arise when I tried 
>> > my scripts were some latex was included in the animation.
>> >
>>
>> Ah, I love 3b1b! Great videos. I toyed with manim once (wanting to
>> create new Fourier visualizations), but the open source parts weren't
>> enough for what I was trying to do. Very cool though.
>>
>
> If you can tell, what parts did you miss?

Basically everything to do with Fourier transforms. I wanted to hand
the program a new SVG file and see it animate it, but (a) I didn't
understand the code very well, and (b) a lot of the code isn't part of
the freely licensed part (it's all in the same repo, but some is
MIT-licensed and isn't), which means it's not documented for public
use and isn't designed to be broadly usable.

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

Re: Difference between os.path.isdir and Path.is_dir

[Kirill Balunov]

чт, 25 июл. 2019 г. в 22:58, Chris Angelico :

> On Fri, Jul 26, 2019 at 5:52 AM Kirill Balunov 
> wrote:
> [...]
> > No, it's not just because of curiosity. I will try to tell the
> background, and maybe I went the wrong way initially. There is a very cool
> project https://github.com/3b1b/manim, it allows you to visualize math (I
> don’t know how to describe it better you can see some examples here
> https://www.3blue1brown.com) and it works lovely on Linux. For some
> reason, I need to use it on Windows. Problems began to arise when I tried
> my scripts were some latex was included in the animation.
> >
>
> Ah, I love 3b1b! Great videos. I toyed with manim once (wanting to
> create new Fourier visualizations), but the open source parts weren't
> enough for what I was trying to do. Very cool though.
>
>
If you can tell, what parts did you miss?

with kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Difference between os.path.isdir and Path.is_dir

[Chris Angelico]

On Fri, Jul 26, 2019 at 5:52 AM Kirill Balunov  wrote:
>
>
>
> чт, 25 июл. 2019 г. в 19:16, Chris Angelico :
>>
>> On Fri, Jul 26, 2019 at 1:30 AM Kirill Balunov  
>> wrote:
>> >
>> >  Hi all! It is expected that:
>> > ```
>> > >>> import os
>> > >>> from pathlib import Path
>> > >>> dummy = " "   # or "" or " "
>> > >>> os.path.isdir(dummy)
>> > False
>> > >>> Path(dummy).is_dir()
>> > True
>> > ```
>> >
>> > or was it overlooked?
>> >
>> []
>> I'm not sure if this is considered an important enough bug to actually fix, 
>> or
>> if it's merely a curiosity that occurs when you trigger undocumented
>> behaviour.
>>
>
> No, it's not just because of curiosity. I will try to tell the background, 
> and maybe I went the wrong way initially. There is a very cool project 
> https://github.com/3b1b/manim, it allows you to visualize math (I don’t know 
> how to describe it better you can see some examples here 
> https://www.3blue1brown.com) and it works lovely on Linux. For some reason, I 
> need to use it on Windows. Problems began to arise when I tried my scripts 
> were some latex was included in the animation.
>

Ah, I love 3b1b! Great videos. I toyed with manim once (wanting to
create new Fourier visualizations), but the open source parts weren't
enough for what I was trying to do. Very cool though.

> So I installed TexLive, but it didn't produce any output :) In `manim` it is 
> invoked through a system call 
> https://github.com/3b1b/manim/blob/master/manimlib/utils/tex_file_writing.py#L40
>  like this:
>
> $ latex -interaction=batchmode -halt-on-error -output-directory=... input.tex 
> > /dev/null
>
> For some reason TexLive does not understand Windows relative paths of this 
> form -output-directory =".\Output" and  ".\Input\file.tex", but it 
> understands the absolute paths in Windows form like 
> "C:\path\to\the\input\file.tex". I read that Windows allows also to provide 
> paths in the usual form "./Input/file.tex" (maybe I'm wrong with my 
> understanding what does it mean on Windows),
>

It means the same thing as your other relative path. The two types of
slash should basically be interchangeable.

> I've tested and this worked. But the problem is that Python always inserts 
> '\' as path separators on Windows and there is no control to set it up. I 
> decided to rewrite all this stuff with the help of `pathlib` module and to 
> use `Path`  and `.as_posix` method everywhere. Paths are set here 
> https://github.com/3b1b/manim/blob/c7e6d9d4742ec47098bd86a9bbb4212cc637206b/manimlib/constants.py#L10
>  and the author uses  `MEDIA_DIR = ""` as a default unset value, and then 
> checks  `if not os.path.isdir(MEDIA_DIR)`. The documentation states that  
> `os.path.isdir(...)` is equivalent to `Path(...).is_dir()` but it is not 
> true. So I wrote here.
>

Gotcha. It'd probably be safe to change it to "." instead; that way,
it's an actual valid directory name and can be combined normally with
other components.

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

Re: Difference between os.path.isdir and Path.is_dir

[Kirill Balunov]

чт, 25 июл. 2019 г. в 19:16, Chris Angelico :

> On Fri, Jul 26, 2019 at 1:30 AM Kirill Balunov 
> wrote:
> >
> >  Hi all! It is expected that:
> > ```
> > >>> import os
> > >>> from pathlib import Path
> > >>> dummy = " "   # or "" or " "
> > >>> os.path.isdir(dummy)
> > False
> > >>> Path(dummy).is_dir()
> > True
> > ```
> >
> > or was it overlooked?
> >
> []
> I'm not sure if this is considered an important enough bug to actually
> fix, or
> if it's merely a curiosity that occurs when you trigger undocumented
> behaviour.
>
>
No, it's not just because of curiosity. I will try to tell the background,
and maybe I went the wrong way initially. There is a very cool project
https://github.com/3b1b/manim, it allows you to visualize math (I don’t
know how to describe it better you can see some examples here
https://www.3blue1brown.com) and it works lovely on Linux. For some reason,
I need to use it on Windows. Problems began to arise when I tried my
scripts were some latex was included in the animation.
So I installed TexLive, but it didn't produce any output :) In `manim` it
is invoked through a system call
https://github.com/3b1b/manim/blob/master/manimlib/utils/tex_file_writing.py#L40
like this:

$ latex -interaction=batchmode -halt-on-error -output-directory=...
input.tex > /dev/null

For some reason TexLive does not understand Windows relative paths of this
form -output-directory =".\Output" and  ".\Input\file.tex", but it
understands the absolute paths in Windows form like
"C:\path\to\the\input\file.tex".
I read that Windows allows also to provide paths in the usual form
"./Input/file.tex"
(maybe I'm wrong with my understanding what does it mean on Windows), I've
tested and this worked. But the problem is that Python always inserts '\'
as path separators on Windows and there is no control to set it up. I
decided to rewrite all this stuff with the help of `pathlib` module and to
use `Path`  and `.as_posix` method everywhere. Paths are set here
https://github.com/3b1b/manim/blob/c7e6d9d4742ec47098bd86a9bbb4212cc637206b/manimlib/constants.py#L10
and the author uses  `MEDIA_DIR = ""` as a default unset value, and then
checks  `if not os.path.isdir(MEDIA_DIR)`. The documentation states that
`os.path.isdir(...)` is equivalent to `Path(...).is_dir()` but it is not
true. So I wrote here.

with kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Difference between os.path.isdir and Path.is_dir

[Kirill Balunov]

чт, 25 июл. 2019 г. в 20:28, eryk sun :

> On 7/25/19, Kirill Balunov  wrote:
> >
>  import os
>  from pathlib import Path
>  dummy = " "   # or "" or " "
>  os.path.isdir(dummy)
> > False
>  Path(dummy).is_dir()
> > True
>
> I can't reproduce the above result in either Linux or Windows. The
> results should only be different for an empty path string, since
> Path('') is the same as Path('.'). The results should be the same for
> Path(" "), depending on whether a directory named " " exists (normally
> not allowed in Windows, but Linux allows it).
>
>
Heh, something fishy is going on. I also can't reproduce that behavior
(with " " and "   ") at home comp on Windows 10 Python 3.7.4. Tomorrow I'll
check again at work and let you know. I apologize in advance. The main
problem arose огые with an empty line, but then I checked with " " and
apparently made a mistake somewhere.

with kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Difference between os.path.isdir and Path.is_dir

[Maksim Fomin via Python-list]

‐‐‐ Original Message ‐‐‐
On Thursday, July 25, 2019 3:27 PM, Kirill Balunov  
wrote:

> Hi all! It is expected that:
>
> >>> import os
> >>> from pathlib import Path
> >>> dummy = " "   # or "" or " "
> >>> os.path.isdir(dummy)
>
> False
> >>> Path(dummy).is_dir()
>
> True
>
>
> or was it overlooked?
>
> with kind regards,
> -gdg
>
> -
>
> https://mail.python.org/mailman/listinfo/python-list

I also cannot reproduce it on linux (python 3.7.3). Which version do you use?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Difference between os.path.isdir and Path.is_dir

[eryk sun]

On 7/25/19, Chris Angelico  wrote:
> On Fri, Jul 26, 2019 at 3:54 AM eryk sun  wrote:
>
>> That's what I said. But the OP shows os.path.isdir(" ") == False and
>> Path(" ").is_dir() == True, which is what I cannot reproduce and
>> really should not be able to reproduce, unless there's a bug
>> somewhere.
>
> Yeah but WHY is it different for an empty string?

Path.__fspath__ returns str(self), and Path.__str__ returns "." if the
path is empty, i.e. there's no drive, root, or parts.

I assume this is related to os.path.normpath("") == ".", which is
related to os.path.normpath("spam/..") == ".". However, an empty path
string isn't consistently handled as the current directory throughout
the os and os.path modules.

> I can well imagine that some OS/FS combinations will happily strip
> spaces, thus devolving the " " case to the "" one.

Windows trims trailing spaces and dots from the final component of a
path, unless we use a non-normalized \\?\ path.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Difference between os.path.isdir and Path.is_dir

[Chris Angelico]

On Fri, Jul 26, 2019 at 3:54 AM eryk sun  wrote:
>
> On 7/25/19, Chris Angelico  wrote:
> > On Fri, Jul 26, 2019 at 3:28 AM eryk sun  wrote:
> >>
> >> On 7/25/19, Kirill Balunov  wrote:
> >> >
> >>  import os
> >>  from pathlib import Path
> >>  dummy = " "   # or "" or " "
> >>  os.path.isdir(dummy)
> >> > False
> >>  Path(dummy).is_dir()
> >> > True
> >>
> >> I can't reproduce the above result in either Linux or Windows. The
> >> results should only be different for an empty path string, since
> >> Path('') is the same as Path('.'). The results should be the same for
> >> Path(" "), depending on whether a directory named " " exists (normally
> >> not allowed in Windows, but Linux allows it).
> >
> > Try an empty string, no spaces. To pathlib.Path, that means the
> > current directory. To os.path.abspath, that means the current
> > directory. To os.stat, it doesn't exist.
>
> That's what I said. But the OP shows os.path.isdir(" ") == False and
> Path(" ").is_dir() == True, which is what I cannot reproduce and
> really should not be able to reproduce, unless there's a bug
> somewhere.

Yeah but WHY is it different for an empty string?

I can well imagine that some OS/FS combinations will happily strip
spaces, thus devolving the " " case to the "" one.

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

Re: Difference between os.path.isdir and Path.is_dir

[eryk sun]

On 7/25/19, Chris Angelico  wrote:
> On Fri, Jul 26, 2019 at 3:28 AM eryk sun  wrote:
>>
>> On 7/25/19, Kirill Balunov  wrote:
>> >
>>  import os
>>  from pathlib import Path
>>  dummy = " "   # or "" or " "
>>  os.path.isdir(dummy)
>> > False
>>  Path(dummy).is_dir()
>> > True
>>
>> I can't reproduce the above result in either Linux or Windows. The
>> results should only be different for an empty path string, since
>> Path('') is the same as Path('.'). The results should be the same for
>> Path(" "), depending on whether a directory named " " exists (normally
>> not allowed in Windows, but Linux allows it).
>
> Try an empty string, no spaces. To pathlib.Path, that means the
> current directory. To os.path.abspath, that means the current
> directory. To os.stat, it doesn't exist.

That's what I said. But the OP shows os.path.isdir(" ") == False and
Path(" ").is_dir() == True, which is what I cannot reproduce and
really should not be able to reproduce, unless there's a bug
somewhere.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Difference between os.path.isdir and Path.is_dir

[Chris Angelico]

On Fri, Jul 26, 2019 at 3:28 AM eryk sun  wrote:
>
> On 7/25/19, Kirill Balunov  wrote:
> >
>  import os
>  from pathlib import Path
>  dummy = " "   # or "" or " "
>  os.path.isdir(dummy)
> > False
>  Path(dummy).is_dir()
> > True
>
> I can't reproduce the above result in either Linux or Windows. The
> results should only be different for an empty path string, since
> Path('') is the same as Path('.'). The results should be the same for
> Path(" "), depending on whether a directory named " " exists (normally
> not allowed in Windows, but Linux allows it).

Try an empty string, no spaces. To pathlib.Path, that means the
current directory. To os.path.abspath, that means the current
directory. To os.stat, it doesn't exist.

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

Re: Difference between os.path.isdir and Path.is_dir

[eryk sun]

On 7/25/19, Kirill Balunov  wrote:
>
 import os
 from pathlib import Path
 dummy = " "   # or "" or " "
 os.path.isdir(dummy)
> False
 Path(dummy).is_dir()
> True

I can't reproduce the above result in either Linux or Windows. The
results should only be different for an empty path string, since
Path('') is the same as Path('.'). The results should be the same for
Path(" "), depending on whether a directory named " " exists (normally
not allowed in Windows, but Linux allows it).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Difference between os.path.isdir and Path.is_dir

[Chris Angelico]

On Fri, Jul 26, 2019 at 1:30 AM Kirill Balunov  wrote:
>
>  Hi all! It is expected that:
> ```
> >>> import os
> >>> from pathlib import Path
> >>> dummy = " "   # or "" or " "
> >>> os.path.isdir(dummy)
> False
> >>> Path(dummy).is_dir()
> True
> ```
>
> or was it overlooked?
>

Was not aware of that. A bit of digging shows that asking to convert
an empty path to an absolute one will give you the name of the current
directory (whether you use os.path or pathlib.Path), but os.path.isdir
starts by seeing if it can os.stat the given path, and if that fails,
it returns False (because if something doesn't exist, it can't be a
directory).

As a workaround, you could simply call
os.path.isdir(os.path.abspath(x)) to get consistent results. I'm not
sure if this is considered an important enough bug to actually fix, or
if it's merely a curiosity that occurs when you trigger undocumented
behaviour.

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

Difference between os.path.isdir and Path.is_dir

[Kirill Balunov]

 Hi all! It is expected that:
```
>>> import os
>>> from pathlib import Path
>>> dummy = " "   # or "" or " "
>>> os.path.isdir(dummy)
False
>>> Path(dummy).is_dir()
True
```

or was it overlooked?

with kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Difference between array( [1,0,1] ) and array( [ [1,0,1] ] )

[Markos]

Thanks Edmondo, Stephen, Mats and Steven you for the tips,

I studied linear algebra many years ago and I remember only a few rudiments.

But I was trying to visualize (in a geometric way) how the numpy 
represents arrays, and what the geometrical meaning of the transpose 
operation made by numpy.


I think I understood a little bit more.

The number of nested brackets indicates the number of array dimensions.
the vector ( [1,2] ) is one-dimensional, but the vector ( [ [1,2] ] ) is 
two-dimensional.


v_1 = np.array( [1,2] )
> v_1.shape
(2,)
> v_1
v_1
> v_1
array( [1, 2] )
> v_2 = np.array( [ [1,2] ] )
> v_2.shape
(1, 2)

And it does not make sense to transpose a one-dimensional array.

> v_1.T
array( [1, 2] )
> v_2.T
array( [ [1],
 [2] ] )

Anothe example:

vector_1 = np.array( [   1,   2,   3,   4,   5,   6,   7,   8  ] )

  ^

vector_2 = np.array( [    [1, 2, 3, 4],    [5, 6, 7, 8]  ]  )

  ^  ^

vector_3 = np.array( [   [   [1,2],  [3,4]  ], [  [5,6],   [7,8] ]  ]  )

  ^ ^ ^

> vector_1
array([1, 2, 3, 4, 5, 6, 7, 8])
> vector_2
array( [ [1, 2, 3, 4],
 [5, 6, 7, 8] ] )
> vector_3
array( [ [ [1, 2],
   [3, 4] ],

 [ [5, 6],
   [7, 8] ] ] )

And looking for some tutorial about geometric aspects of matrices and 
the geometric meaning of the transpose I found that transposed is 
"mirrored along the diagonal" at:


https://www.coranac.com/documents/geomatrix/

>vector_1.T
array([1, 2, 3, 4, 5, 6, 7, 8])
> vector_2.T
array( [ [1, 5],
 [2, 6],
 [3, 7],
 [4, 8] ] )
> vector_3.T
array( [ [ [1, 5],
   [3, 7]],

 [ [2, 6],
   [4, 8] ] ] )

Thank you,
Markos

Em 21-06-2019 07:44, edmondo.giovanno...@gmail.com escreveu:

Every array in numpy has a number of dimensions,
"np.array" is a function that can create an array numpy given a list.

when  you write
vector_1  = np.array([1,2,1])
you are passing a list of number to thet function array that will create a 1D 
array.
As you are showing:
vector_1.shape
will return a tuple with the sizes of each dimension of the array that is:
(3,)
Note the comma thta indicate that is a tuple.
While if you write:
vector_2 = np.array([[1,2,3]])
You are passing a list of list to the function array that will instruct it to 
crete a 2D array, even though the size of the first dimension is 1:
vector_2.shape
(1,3)
It is still a tuple as you can see.
Try:
vector_3 = np.array([[1,2,3],[4,5,6]])
And you'll see that i'll return a 2D array with a shape:
vector_3.shape
(2,3)
As the external list has 2 elements that is two sublists each with 3 elements.
The vector_2 case is just when the external list has only 1 element.

I hope it is more clear now.
Cherrs,

   

   
   


Il giorno venerdì 21 giugno 2019 08:29:36 UTC+2, Markos ha scritto:

Hi,

I'm studying Numpy and I don't understand the difference between


vector_1 = np.array( [ 1,0,1 ] )

with 1 bracket and


vector_2 = np.array( [ [ 1,0,1 ] ] )

with 2 brackets

The shape of vector_1 is:


vector_1.shape

(3,)

But the shape of vector_2 is:


vector_2.shape

(1, 3)

The transpose on vector_1 don't work:


vector_1.T

array([1, 0, 1])

But the transpose method in vector_2 works fine:


vector_2.T

array([[1],
     [0],
     [1]])


I thought that both vectors would be treated as an matrix of 1 row and 3
columns.

Why this difference?

Any tip?

Thank you,
Markos


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

Re: Difference between array( [1,0,1] ) and array( [ [1,0,1] ] )

[MRAB]

On 2019-06-21 02:39, Markos wrote:


Hi,

I'm studying Numpy and I don't understand the difference between


vector_1 = np.array( [ 1,0,1 ] )


with 1 bracket and


vector_2 = np.array( [ [ 1,0,1 ] ] )


with 2 brackets

The shape of vector_1 is:


vector_1.shape

(3,)

But the shape of vector_2 is:


vector_2.shape

(1, 3)

The transpose on vector_1 don't work:


vector_1.T

array([1, 0, 1])

But the transpose method in vector_2 works fine:


vector_2.T

array([[1],
     [0],
     [1]])


I thought that both vectors would be treated as an matrix of 1 row and 3
columns.

Why this difference?

By similar reasoning, why not 3-dimensional (layer, row, column)? Or 
4-dimensional?

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

Re: Difference between array( [1,0,1] ) and array( [ [1,0,1] ] )

[edmondo . giovannozzi]

Keep also in mind that numpy is quite different from Matlab.
In Matlab every vaiable is a matrix of at least 2 dimensions.

This is not the case of numpy (and is not the case in Fortran too).
every array can have a different number of dimensions. The transposition of an 
array with just 1 dimension is not really meaningful.
On the other hand most of the time is not needed.
For example le have a matrix:
a = np.array([[1,2],[1,1]])
and an array:
b = np.array([0.1,0.2])
You can left multiply or right multiply it to this matrix without any need to 
transpose it  (as you have to do in Matlab):
a @ b
array([0.5,0.3])
b @ a
array([0.3,0.4])
Cheers,


 

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