Re: convert a string to a variable

[dieter]

bruceg113...@gmail.com writes:

> I am trying to convert a string to a variable.
>
> I got cases 1 & 2 to work, but not cases 3 & 4.
>
> The print statement in cases 3 & 4 reports the following:
> builtins.AttributeError: type object 'animal' has no attribute 'tiger'
> 
> I am stuck on creating variables that can be accessed as follows.
>   animal.tiger
>   self.animal.tiger
>
> Any suggestions?
> ...
> # Case 3: This does not work
> indata = 'animal.tiger'
> vars()[indata] = "Tigers, big and strong!"
> print (animal.tiger)

In the expression "animal.tiger", the "variable" is "animal",
not "animal.tiger". It is evaluated as follows:
determine the object bound to "animal", access its attribute "tiger".
Your error message tells you that the first step (object bound
to "animal") has been successful, but the result lacks the
attribute "tiger".

> #Case 4: This does not work
> class animal():
> def create (self, indata):
> vars(self)[indata] = "Tigers, big and strong!"

Here you want to define the attribute "tiger" (I think),
not "animal.tiger". Note that the "." in a Python expression
(not a string) separates two individual steps: determine
an object corresponding to the leftside to the "."; access
the attribute corresponding to the name following the ".".
> print (self.animal.tiger)
>
> tmp = animal()
> tmp.create('animal.tiger')

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

Re: List replication operator

[Cameron Simpson]

On 25May2018 02:32, Steven D'Aprano  
wrote:

On Fri, 25 May 2018 08:02:38 +1000, Cameron Simpson wrote:


I'm also against the "**" spelling I find, for much the same reasons
that people oppose allowing "=" and "==" in the same syntactic location:
they're easy to get wrong through typing inaccuracy.


Do you often write

  y = 2**x

when you meant 2*x?


Well, no, but in that context they mean very different things. Your * vs ** 
mean very similar things.



In any case, I'm not wedded to the ** spelling, MRAB's suggestion of @
would work for me too.


Hmm, perhaps.

I rarely use the * list replicator myself (though I used it just the other day 
to prefill a list with None). What's your commonest use case? And also, what's 
you're commonest use case which is prone the the issue a shallow copy would 
help with?


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

Re: List replication operator

[Cameron Simpson]

On 25May2018 02:25, Steven D'Aprano  
wrote:

On Thu, 24 May 2018 15:12:09 -0400, Ned Batchelder wrote:

On 5/24/18 2:17 PM, Steven D'Aprano wrote:

[...]

But what do people think about proposing a new list replication with
copy operator?

 [[]]**5

would return a new list consisting of five shallow copies of the inner
list.


"shallow" will be the next problem.  Do we also need this?:

     [[[]]]***5 # j/k


You might be right: on further thought, I think I want deep copies, not
shallow.

Originally I thought that deep copies was an YAGNI. Have you *ever* seen
anyone complain that * didn't make a deep copy of the list contents? I
never have. But then I realised that if this works, people will surely
try to use it to make three-dimensional lists as well as two, and for
that we need deep copies.


In the deep copy scenario I am far far less opposed - _that_ is practically 
exponential memory use, and so the "**" is much more apt :-)


I think I'm basicly against a shallow copy and not against a deep copy, because 
the shallow copy only pushes the issue out one layer.


So, how to various forms of multidimensional lists play out as code?

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

[issue32911] Doc strings no longer stored in body of AST

[Ned Deily]

Ned Deily  added the comment:

Based on more recent discussions and indirect feedback from downstream users 
(primarily the recent IPython experience), I am reluctantly re-opening this 
issue for 3.7.0.  I take responsibility for encouraging us earlier in the beta 
phase to continue with the feature as it stood, thereby prioritizing schedule 
over any technical issues.  Although it is now very late in the 3.7.0 cycle, 
with the newly expressed concerns my opinion has changed: I think we owe it to 
our downstream users to think about this one more time.

I agree with Benjamin's remark that it is very late in the 3.7 cycle to be 
considering new or revised APIs for 3.7.0.  So it seems to me we have only two 
practical alternatives at this point:

A. Proceed with 3.7.0rc1 as planned with the docstrings feature as it now 
stands and consider API changes for 3.8.

or

B. Revert the feature now for 3.7.0, retargeting for 3.8, and produce a 3.7.0b5 
on a somewhat shorter cycle to allow downstream users to adapt to the removal.

I don't know how controversial making this decision will be but I think we need 
to move quickly as this is now *the* blocker for 3.7.0.  Coming now at the 
start of a weekend, in some countries a 3-day holiday weekend, I do want to 
make sure that the major stakeholders involved with this issue get a chance to 
"vote", although ultimately it will be up to the release manager (me) to make 
the final decision.  So, to be clear, we will not be deciding here and now what 
the API should be if we were to retarget for 3.8; please save that discussion 
for later.  The only question open right now is a vote for either option A 
(proceed as is) or option B (revert for 3.7 and retarget).  Let's set a limit 
for "voting" until Tuesday 2018-05-29 18:00 UTC (to cover the holiday weekend) 
with the proviso that if a clear consensus one way or the other appears before 
that we may cut the period short and proceed to implemention.

I know this is not a pleasant task especially at this late date.  I apologize 
to everyone, especially to Inada-san, for dragging this out.  I certainly 
appreciate the hard work that has gone into this feature so far and look 
forward to seeing it in either 3.7 or 3.8.

--
priority:  -> release blocker
resolution: wont fix -> 
stage: resolved -> commit review
status: closed -> open

___
Python tracker 

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

[issue33616] typing.NoReturn is undocumented

[miss-islington]

Change by miss-islington :


--
pull_requests: +6748

___
Python tracker 

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

Raw string statement (proposal)

[Mikhail V]

Hi.
I've put some thoughts together, and
need some feedback on this proposal.
Main question is:  Is it convincing?
Is there any flaw?
My own opinion - there IS something to chase.
Still the justification for such syntax is hard.



Raw string statement
--

Issue
-

Vast majority of tasks include operations with text in
various grades of complexity. It is relevant even by
simple ubiquitous tasks, like for example defining file paths.
String literals are interpreted - i.e. special character "\" may
change the contents of a string.
Python raw string r"" has the least amount of such cases :
namely the inclusion of the quote character requires escaping.
There is still no string type which is totally uninterpreted.
As a result, any text piece that contains a quote must
be *edited* before it can be used in sources.

This may seem a minor problem, but if we count all
cases, then the cumulative long-term impact may be significant.
Also this problem may become more acute in cases related to:
- development of text/code generators
- and, in general, all text processing with a lot of
  literal data definition
- proofreading

Such applications may *require* a lot of embedded text definitions and
this may even lead to frustration by proofreading of 'escaped' pieces
and it adds necessity for keeping track of changes in these pieces.
Using external resources for these tasks could help, but it may lead to
even worse experience because of spread definitions
and increased maintenance times.

The most common solution in existing syntax - triple quoted
strings and raw strings has some additional issues:

- Data is parsed including indents. This may be a benefit for some
cases (e.g. start lines always without any indent) but it also may
become confusing for the readers when not aligned with
containing block. So-called "de-denting" is also needed.

- Triple quotes cause visual ambiguity in some edge-cases,
e.g. when a string starts or ends with a quote. Also in many fonts
a pair of single quotes is visually identical to one double quote.


Proposal
---

Current proposal suggests adding syntax for the "raw text" statement.
This should enable the possibility to define text pieces in source
code without the need for interpreted characters.
Thereby it should solve the mentioned issues.
Additionally it should solve some issues with visual appearance.


Specification
-

Raw string statement has the following form:

name >>> "condition_string"
... text ...

in example:

data >>> "  "
  begin
  end
#rest

will parse the block by comparing each next
line part with the string "  " (2 spaces here).
This will return: "  begin\n  end"

-- Additional option: parse and remove:

data >>> !"  "
  begin
  end
#rest

Will parse by the same rule but also remove
the string from the result: "begin\nend"

- Additional option: parse *until* condition:

data >>> ?"#eof"
begin
end
#eof

Will parse up to character sequence "#eof" (if it is on the
same level) and returns: "begin\nend".
The benefit of last option - the data can be put at zero
level. It may be also prefered due to explicit terminator.


General rules:

- parsing is aware of the indent of containing
  block, i.e. no de-dention needed.
- single line assignment may be allowed with
  some restrictions.

Difficulties:

- change of core parsing rules
- backward compatibility broken
- syntax highlighting may not work
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue33616] typing.NoReturn is undocumented

[miss-islington]

Change by miss-islington :


--
pull_requests: +6747

___
Python tracker 

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

[issue33351] Support compiling with clang-cl on Windows

[Ethan Smith]

Ethan Smith  added the comment:

After wrangling with some missing compiler intrinsics, I've been able to get 
CPython to build with an almost vanilla clang-cl!

I plan on upstreaming the patches to the LLVM project once I clean them up a 
bit. After that I will clean up the CPython patches and send a PR.

I also ran performance with master built on MSVC compared to my branch on 
clang-cl with computed-goto enabled (I wasn't sure if there are other things 
that may be possible to turn on, computed goto seemed an obvious win). The 
results are decent, but some things, like json loads, are much slower (not sure 
why that is). The full report:


msvc.json
=

Performance version: 0.6.1
Report on Windows-10-10.0.17672-SP0
Number of logical CPUs: 12
Start date: 2018-05-24 03:40:09.082701
End date: 2018-05-24 04:08:57.993717

clang2goto.json
===

Performance version: 0.6.1
Report on Windows-10-10.0.17672-SP0
Number of logical CPUs: 12
Start date: 2018-05-24 04:29:01.214005
End date: 2018-05-24 04:57:08.774299

### 2to3 ###
Mean +- std dev: 675 ms +- 31 ms -> 655 ms +- 32 ms: 1.03x faster
Significant (t=3.55)

### chameleon ###
Mean +- std dev: 19.5 ms +- 0.5 ms -> 18.1 ms +- 0.7 ms: 1.08x faster
Significant (t=13.19)

### chaos ###
Mean +- std dev: 230 ms +- 6 ms -> 209 ms +- 8 ms: 1.10x faster
Significant (t=16.39)

### crypto_pyaes ###
Mean +- std dev: 212 ms +- 8 ms -> 197 ms +- 8 ms: 1.07x faster
Significant (t=9.72)

### deltablue ###
Mean +- std dev: 15.2 ms +- 0.6 ms -> 14.2 ms +- 0.5 ms: 1.07x faster
Significant (t=10.23)

### django_template ###
Mean +- std dev: 222 ms +- 9 ms -> 210 ms +- 8 ms: 1.06x faster
Significant (t=8.10)

### dulwich_log ###
Mean +- std dev: 235 ms +- 13 ms -> 230 ms +- 12 ms: 1.02x faster
Significant (t=2.18)

### fannkuch ###
Mean +- std dev: 905 ms +- 11 ms -> 802 ms +- 15 ms: 1.13x faster
Significant (t=42.95)

### float ###
Mean +- std dev: 226 ms +- 9 ms -> 197 ms +- 8 ms: 1.15x faster
Significant (t=18.71)

### go ###
Mean +- std dev: 485 ms +- 10 ms -> 445 ms +- 8 ms: 1.09x faster
Significant (t=24.60)

### hexiom ###
Mean +- std dev: 19.9 ms +- 0.9 ms -> 18.3 ms +- 0.8 ms: 1.08x faster
Significant (t=9.51)

### html5lib ###
Mean +- std dev: 156 ms +- 9 ms -> 149 ms +- 9 ms: 1.05x faster
Significant (t=4.31)

### json_dumps ###
Mean +- std dev: 23.4 ms +- 1.2 ms -> 23.0 ms +- 1.1 ms: 1.02x faster
Not significant

### json_loads ###
Mean +- std dev: 49.3 us +- 2.2 us -> 93.2 us +- 8.7 us: 1.89x slower
Significant (t=-37.79)

### logging_format ###
Mean +- std dev: 25.3 us +- 1.3 us -> 23.4 us +- 1.2 us: 1.08x faster
Significant (t=8.48)

### logging_silent ###
Mean +- std dev: 368 ns +- 14 ns -> 340 ns +- 21 ns: 1.08x faster
Significant (t=8.69)

### logging_simple ###
Mean +- std dev: 23.1 us +- 1.4 us -> 20.6 us +- 0.9 us: 1.12x faster
Significant (t=11.66)

### mako ###
Mean +- std dev: 36.7 ms +- 1.8 ms -> 36.0 ms +- 1.7 ms: 1.02x faster
Not significant

### meteor_contest ###
Mean +- std dev: 189 ms +- 9 ms -> 175 ms +- 9 ms: 1.08x faster
Significant (t=9.09)

### nbody ###
Mean +- std dev: 274 ms +- 12 ms -> 222 ms +- 8 ms: 1.24x faster
Significant (t=28.22)

### nqueens ###
Mean +- std dev: 198 ms +- 8 ms -> 174 ms +- 8 ms: 1.14x faster
Significant (t=16.67)

### pathlib ###
Mean +- std dev: 343 ms +- 19 ms -> 338 ms +- 18 ms: 1.02x faster
Not significant

### pickle ###
Mean +- std dev: 20.9 us +- 0.8 us -> 19.9 us +- 0.5 us: 1.05x faster
Significant (t=8.91)

### pickle_dict ###
Mean +- std dev: 50.0 us +- 1.9 us -> 51.2 us +- 3.0 us: 1.02x slower
Significant (t=-2.62)

### pickle_list ###
Mean +- std dev: 7.61 us +- 0.32 us -> 7.06 us +- 0.36 us: 1.08x faster
Significant (t=8.92)

### pickle_pure_python ###
Mean +- std dev: 964 us +- 52 us -> 879 us +- 43 us: 1.10x faster
Significant (t=9.72)

### pidigits ###
Mean +- std dev: 257 ms +- 5 ms -> 254 ms +- 9 ms: 1.01x faster
Not significant

### python_startup ###
Mean +- std dev: 69.6 ms +- 8.3 ms -> 69.5 ms +- 6.3 ms: 1.00x faster
Not significant

### python_startup_no_site ###
Mean +- std dev: 57.7 ms +- 6.6 ms -> 58.2 ms +- 6.0 ms: 1.01x slower
Not significant

### raytrace ###
Mean +- std dev: 1.00 sec +- 0.02 sec -> 0.94 sec +- 0.02 sec: 1.07x faster
Significant (t=21.49)

### regex_compile ###
Mean +- std dev: 335 ms +- 5 ms -> 306 ms +- 10 ms: 1.10x faster
Significant (t=20.75)

### regex_dna ###
Mean +- std dev: 237 ms +- 7 ms -> 266 ms +- 7 ms: 1.13x slower
Significant (t=-23.71)

### regex_effbot ###
Mean +- std dev: 4.42 ms +- 0.17 ms -> 4.82 ms +- 0.20 ms: 1.09x slower
Significant (t=-12.07)

### regex_v8 ###
Mean +- std dev: 45.2 ms +- 15.5 ms -> 39.7 ms +- 2.8 ms: 1.14x faster
Significant (t=2.74)

### richards ###
Mean +- std dev: 152 ms +- 8 ms -> 142 ms +- 9 ms: 1.07x faster
Significant (t=6.19)

### scimark_fft ###
Mean +- std dev: 665 ms +- 12 ms -> 593 ms +- 12 ms: 1.12x faster
Significant (t=32.36)

### scimark_lu ###
Mean +- std dev: 327 ms +- 11 ms -> 

[issue32911] Doc strings no longer stored in body of AST

[Ned Deily]

Ned Deily  added the comment:

For the record, Serhiy commented on this issue today in a thread on the 
python-committers list:

"I have doubts about two issues. I feel the responsibility for them because I 
had the opportunity to solve them before, but I lost it.

1. Changes in the AST. Few third-party projects was broken by it and already 
are fixed. I suppose yet few projects will be changed after 3.7 be released. It 
is interesting that IPython was broken in different way than other projects. It 
was needed to reintroduce the docstring in the list of statements, effectively 
reverting the 3.7 change. IPython allows to enter several statements at prompt, 
and therefore it compiles them with the 'exec' mode instead of 'single' as the 
CPython REPL and IDLE shell. Currently CPython doesn't allow you to paste 
arbitrary script like the following:

if a:
b
if c:
d

You need to add an empty line between top-level complex statements. If one time 
CPython will add support of pasting several statements without empty lines 
between, it might need to add the same hack as IPython. I afraid that we might 
be needed to change AST again, in 3.7.1 or in 3.8.0."

And later:

"Inada's patch looked complex (actually it mostly restored the code before his 
previous change). We didn't know about IPython and we decided that it is not 
worth to change this code at this stage (after beta2). And definitely it will 
be later to do this after rc1."

Full context/content starting here:
https://mail.python.org/pipermail/python-committers/2018-May/005467.html

--

___
Python tracker 

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

[issue32911] Doc strings no longer stored in body of AST

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Regardless of the value of .docstring change, it seems it had some unexpected 
consequences. I think providing a new mode for compile mulitline statements is 
a reasonable way to address those consequences going forward. That said, it's 
extremely late in the lifecycle of 3.7 to be thinking about new APIs. How about 
rolling back the whole .docstring change for 3.7? Then, it can be landed again 
with compile(..., mode='multiline) for 3.8.

--

___
Python tracker 

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

Re: List replication operator

[Paul]

how often would people here have needed this new operator, if it had
existed?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: cleaner version of variable, new line

[asa32sd23]

On Thursday, May 24, 2018 at 8:51:07 PM UTC-4, asa3...@gmail.com wrote:
> hi just seeing if there is a cleaner way to write this. 
>  
> s1= "kitti"
> s2= 'kitti'
> i= 3
> print(s1+ "\n" + "="*i + "^" + "\n" +s2)
> 
> > 
> kitti
> ===^
> kitti

more legible that way... thks
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: List replication operator

[Steven D'Aprano]

On Thu, 24 May 2018 16:05:32 -0700, Paul wrote:

> How would one make a multi-dimensional list now, with truly-separate sub
> lists?  Is there just no way to do it with the replication operator?

Correct. Let's say you want to make a 1-D list with three items 
initialised to zero. This works brilliantly:

py> [0]*3
[0, 0, 0]

This seems like it ought to create a 3x3 2-D list:

py> y = [[0]*3]*3
py> y
[[0, 0, 0], [0, 0, 0], [0, 0, 0]]


but alas, it's a trap:

py> y[0][0] = 1
py> y
[[1, 0, 0], [1, 0, 0], [1, 0, 0]]


The current recommended solution is:

py> y = [[0]*3 for _ in range(3)]
py> y[0][0] = 1
py> y
[[1, 0, 0], [0, 0, 0], [0, 0, 0]]


To get a three-dimensional 3x3x3 list is even more work:

py> z = [[[0]*3 for _ in range(3)] for _ in range(3)]
py> z[0][0][0] = 1
py> z[1][1][1] = 2
py> z[2][2][2] = 3
py> z
[[[1, 0, 0], [0, 0, 0], [0, 0, 0]], 
 [[0, 0, 0], [0, 2, 0], [0, 0, 0]],
 [[0, 0, 0], [0, 0, 0], [0, 0, 3]]]



With my suggestion, we get:

x = [0]**3  # one-dimensional
y = [[0]**3]**3  # two-dimensional
z = [[[0]**3]**3]**3  # three-dimensional

Or there's MRAB's suggestion of using @ instead.

The one-dimensional case can be optimized by using regular * replication 
instead of ** duplication, but that's an optimization for immutable 
objects.


Here's a subclass that implements a simple version of this for testing:

class ML(list):
def __pow__(self, other):
import copy
L = []
for i in range(other):
L.extend(copy.deepcopy(obj) for obj in self)
return ML(L)


And in use to generate a 3-D list:

py> z = ML([ML([ML([0])**3])**3])**3
py> z[0][0][0] = 1
py> z[1][1][1] = 2
py> z[2][2][2] = 3
py> z
[[[1, 0, 0], [0, 0, 0], [0, 0, 0]],
 [[0, 0, 0], [0, 2, 0], [0, 0, 0]],
 [[0, 0, 0], [0, 0, 0], [0, 0, 3]]]


The repeated calls to ML() are ugly and are only there because the [] 
syntax creates ordinary lists, not my subclass.


-- 
Steve

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

Re: List replication operator

[Steven D'Aprano]

On Fri, 25 May 2018 08:02:38 +1000, Cameron Simpson wrote:

> I'm also against the "**" spelling I find, for much the same reasons
> that people oppose allowing "=" and "==" in the same syntactic location:
> they're easy to get wrong through typing inaccuracy.

Do you often write

   y = 2**x

when you meant 2*x?

In any case, I'm not wedded to the ** spelling, MRAB's suggestion of @ 
would work for me too.


-- 
Steve

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

Re: why do I get syntax error on if : break

[Steven D'Aprano]

On Thu, 24 May 2018 19:12:33 -0700, asa32sd23 wrote:

> here is the code, i keep getting an error, "break outside loop". if it
> is false just exit function

break doesn't exit the function, it exits the loop. There is no loop to 
exit, so it is an error.

Believe the compiler when it tells you there is a syntax error with your 
code. The compiler is always correct.



-- 
Steve

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

Re: List replication operator

[Steven D'Aprano]

On Thu, 24 May 2018 15:12:09 -0400, Ned Batchelder wrote:

> On 5/24/18 2:17 PM, Steven D'Aprano wrote:
[...]
>> But what do people think about proposing a new list replication with
>> copy operator?
>>
>>  [[]]**5
>>
>> would return a new list consisting of five shallow copies of the inner
>> list.
>>
> "shallow" will be the next problem.  Do we also need this?:
> 
>      [[[]]]***5 # j/k

You might be right: on further thought, I think I want deep copies, not 
shallow.

Originally I thought that deep copies was an YAGNI. Have you *ever* seen 
anyone complain that * didn't make a deep copy of the list contents? I 
never have. But then I realised that if this works, people will surely 
try to use it to make three-dimensional lists as well as two, and for 
that we need deep copies.


-- 
Steve

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

Re: why do I get syntax error on if : break

[boB Stepp]

On Thu, May 24, 2018 at 9:12 PM,   wrote:
> here is the code, i keep getting an error, "break outside loop". if it is 
> false just exit function
>
>
> def d(idx):
> if type(idx) != int:
> break
>
> d('k')

"break" (and "continue") are only meaningful inside for or while
loops.  You do not have one of these inside your function.  See
https://docs.python.org/3/reference/simple_stmts.html#break

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

Re: cleaner version of variable, new line

[Steven D'Aprano]

On Thu, 24 May 2018 17:50:53 -0700, asa32sd23 wrote:

> hi just seeing if there is a cleaner way to write this.
>  
> s1= "kitti"
> s2= 'kitti'
> i= 3
> print(s1+ "\n" + "="*i + "^" + "\n" +s2)


s = "kitti"
i = 3
print(s, "="*i + "^", s, sep='\n')





-- 
Steve

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

why do I get syntax error on if : break

[asa32sd23]

here is the code, i keep getting an error, "break outside loop". if it is false 
just exit function


def d(idx):
if type(idx) != int:
break

d('k')
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: cleaner version of variable, new line

[MRAB]

On 2018-05-25 01:50, asa32s...@gmail.com wrote:

hi just seeing if there is a cleaner way to write this.
  
s1= "kitti"

s2= 'kitti'
i= 3
print(s1+ "\n" + "="*i + "^" + "\n" +s2)




kitti
===^
kitti


When printing, I'd probably just go for something clear and simple:

print(s1)
print("=" * i + "^")
print(s2)

There's no need to cram it all onto one line.
--
https://mail.python.org/mailman/listinfo/python-list

[issue33616] typing.NoReturn is undocumented

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
keywords: +patch
pull_requests: +6746
stage:  -> patch review

___
Python tracker 

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

Re: Usenet Gateway

[Michael Torrie]

On 05/24/2018 08:20 AM, Grant Edwards wrote:
> But you had to jump through hoops with procmail and server/client side
> filtering to get there.

True, but it takes maybe 30 seconds for each new list I sign up for, and
then it's out of sight, out of mind.  I already do a ton of filtering on
my inbox anyway to move family messages to their own folder, etc.  Hate
to say it, but GMail actually makes it pretty fast and easy to set up
the rule.  Mostly one-click automatic "filter messages like this one."

I agree NNTP is designed for all of this.  I used to spend a lot of time
on Usenet years ago when every uni had its own NNTP server.  And
thunderbird, my preferred client, can use NNTP.  But the mailing list
works and has, for me, almost no spam, so there's no real incentive for
me to change.

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

Re: Usenet Gateway

[Michael Torrie]

On 05/24/2018 07:01 AM, Steven D'Aprano wrote:
> On Thu, 24 May 2018 05:44:26 -0600, Michael Torrie wrote:
> 
>> I agree web forums really suck for any kind of multi-user conversation.
> 
> Oh good. Because the Python core-devs are talking about moving to 
> Github's web interface instead of email. Because Github is the future :-)
> 
> https://circleci.com/blog/its-the-future/
> 
> https://hackernoon.com/its-the-future-again-cd038b72dd0b

That's great news. Sigh.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Usenet Gateway

[Michael Torrie]

On 05/24/2018 07:10 AM, Chris Green wrote:
> A *thread* yes, but not a whole list.  I.e. if you read this using 
> mail/IMAP you can mark a thread read but you can't mark *all* Python 
> list messages read in one go can you?   With tin/Usenet I look at
> the list of new subjects in the Python group, I may investigate a
> couple of threads, then I just hit 'C' and all of the Python group is
> marked as read.

Sure can.  Just right click on the folder that holds all the python
mailing list messages and click "mark folder read."

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

Re: List replication operator

[Steven D'Aprano]

On Thu, 24 May 2018 11:24:41 -0700, Rob Gaddi wrote:

> On 05/24/2018 11:17 AM, Steven D'Aprano wrote:
[...]
>> But what do people think about proposing a new list replication with
>> copy operator?
>> 
>>  [[]]**5
>> 
>> would return a new list consisting of five shallow copies of the inner
>> list.
>> 
>> 
>> Thoughts?
>> 
>> 
>> 
>> 
> I think the same people making that mistake now would still do so
> because they didn't know they needed the special operator.

People aren't born knowing that * is usable with lists, so the fact that 
they won't be born knowing about ** either is not a point against it.

Wherever newbies are learning about * will soon teach them to use ** for 
multi-dimensional lists as well.

> [[] for _ in range(5)] works just as well without adding more syntax.

This doesn't add more syntax. ** is already valid syntax. It is just 
adding a new method to sequences.

For newbies, using a list comp is not obvious or easily discoverable.


-- 
Steve

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

Re: Scripts not downloading Version 3.6.5

[Terry Reedy]

On 5/24/2018 11:31 AM, Chester Davies via Python-list wrote:

Hi!

Yesterday I downloaded the latest version of Python, after some fiddling around 
with some command line, getting Python to open files etc, it wasn't able to 
find various pillows, so after a while, I decided to call it a night. I went to 
finish it off today, and discovered my computer had updated Windows, and so 
decided to uninstall everything and start from scratch. Upon redownloading 
Python 3.6.5, and moving to where I want it, I cannot use any of the functions 
required, mainly pip.exe. Upon looking in the scripts folder, it is completely 
empty. I have since tried to reinstall to no avail, and also attempted to do 
various repairs from the installer. How can I rectify this please?


Run python -m ensurepip --upgrade
See https://docs.python.org/3/library/ensurepip.html#module-ensurepip
There should have been an option to do this with 'repair', but anyway...

--
Terry Jan Reedy

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

[issue33625] Release GIL for grp.getgr{nam, gid} and pwd.getpw{nam, uid}

[Mariatta Wijaya]

Mariatta Wijaya  added the comment:

In the future please use gender-neutral words such as "everyone", "people", or
"folks" instead of "guys". Thanks.

--
nosy: +Mariatta

___
Python tracker 

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

[issue33642] IDLE: Use variable number of lines in CodeContext

[Terry J. Reedy]

Terry J. Reedy  added the comment:

2 quick thoughts.

1. I am not sure we can/should change the default, as it interacts with the 
recorded user changes for past versions.  The default is that we never change 
defaults.  (Having one user config for all Python/IDLE versions is a curse as 
well as a blessing.  I anticipate having to do something different, sometime.

2. I was thinking for '' instead of a blank line for when CC is on 
but there is no real context.  I think we should try both and see what seems 
better in use while moving down through a file.

--
versions: +Python 3.6

___
Python tracker 

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

cleaner version of variable, new line

[asa32sd23]

hi just seeing if there is a cleaner way to write this. 
 
s1= "kitti"
s2= 'kitti'
i= 3
print(s1+ "\n" + "="*i + "^" + "\n" +s2)

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

[issue33610] IDLE: Make multiple improvements to CodeContext

[Cheryl Sabella]

Cheryl Sabella  added the comment:

For item 7 - #33642.

--
dependencies: +IDLE: Use variable number of lines in CodeContext

___
Python tracker 

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

[issue33642] IDLE: Use variable number of lines in CodeContext

[Cheryl Sabella]

Change by Cheryl Sabella :


--
keywords: +patch, patch
pull_requests: +6744, 6745
stage:  -> patch review

___
Python tracker 

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

[issue33642] IDLE: Use variable number of lines in CodeContext

[Cheryl Sabella]

Change by Cheryl Sabella :


--
keywords: +patch
pull_requests: +6744
stage:  -> patch review

___
Python tracker 

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

[issue22703] Idle Code Context menu entrie(s)

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Changing title since 'separation' has already been done.  Adding a user 
configuration option is a separate issue.

--
title: Idle Code Context: separate changing current and future editors -> Idle 
Code Context menu entrie(s)

___
Python tracker 

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

[issue33642] IDLE: Use variable number of lines in CodeContext

[Cheryl Sabella]

New submission from Cheryl Sabella :

Item 7 from #33610:
Change fixed # of lines to variable # of lines as needed, up to limit.  About 
15 is limit for 4-space indents in 80 char lines. 

* Change default number of lines to be 15 in config.
* Label in config dialog.
* Initialize context to be one blank line to show it's turned on.
* Remove padding of blank lines.
* Modify tests to show variable number of lines in context text instead of 
lines scrolling out of view.

Tip: For manual tests, help.py works really well in viewing 15 lines.

--
assignee: terry.reedy
components: IDLE
messages: 317649
nosy: cheryl.sabella, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: Use variable number of lines in CodeContext
type: enhancement
versions: Python 3.7, Python 3.8

___
Python tracker 

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

[issue22703] Idle Code Context: separate changing current and future editors

[Terry J. Reedy]

Terry J. Reedy  added the comment:

An experienced non-CS computer user I asked does not like 'toggle x' or 'switch 
x', but would like whichever of 'show x' and 'hide x' is appropriate (rather 
than both).  For breakpoints, this would mean one menu entry, either 'set 
breakpoint' or 'clear breakpoint', rather than both (as currently).

A few Menu entries are labelled 'Show x'.  They don't need a 'Hide' menu  
variant as hiding is done otherwise.

Checkmarks are OK, but she would prefer an empty box or circle as an dialogs, 
so that clicking more obviously means 'turn on' when in the 'off' state.

It occurs to me now, after  at least 20 years of using menus,  that the logic 
of 'blank' is that 'blank' means 'do something', so that 'check' means 
'something was done, undo it'.  But I think that clicking 'clear breakpoint', 
for instance, is clearer than clicking 'v breakpoint', where 'v' represents a 
checkmark'.

--

___
Python tracker 

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

[issue33615] test__xxsubinterpreters crashed on x86 Gentoo Refleaks 3.x

[Eric Snow]

Eric Snow  added the comment:

no worries :)

--

___
Python tracker 

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

[issue33615] test__xxsubinterpreters crashed on x86 Gentoo Refleaks 3.x

[STINNER Victor]

STINNER Victor  added the comment:

Oh, I didn't know that it was a 3.8-only issue.

--

___
Python tracker 

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

[issue33615] test__xxsubinterpreters crashed on x86 Gentoo Refleaks 3.x

[Eric Snow]

Eric Snow  added the comment:

Correct.  These failures are only on master.

--

___
Python tracker 

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

Re: List replication operator

[MRAB]

On 2018-05-25 00:05, Paul wrote:

How would one make a multi-dimensional list now, with truly-separate sub
lists?  Is there just no way to do it with the replication operator? IE,
would I just have to do
   X = [[], [], [], [], []]

or perhaps write a function to insert new sub lists into a list, or...?


For a list of 5 separate lists:

X = [[] for _ in range(5)]
--
https://mail.python.org/mailman/listinfo/python-list

[issue32493] UUID Module - FreeBSD build failure

[Ned Deily]

Change by Ned Deily :


--
priority: deferred blocker -> 

___
Python tracker 

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

Re: List replication operator

[Ben Finney]

Paul  writes:

> How would one make a multi-dimensional list now, with truly-separate sub
> lists?  Is there just no way to do it with the replication operator? IE,
> would I just have to do
>   X = [[], [], [], [], []]

The expressions in a comprehension are evaluated each time through. So
this is another way to get that result:

foo = [ [] for __ in range(5) ]

-- 
 \ “We now have access to so much information that we can find |
  `\  support for any prejudice or opinion.” —David Suzuki, 2008-06-27 |
_o__)  |
Ben Finney

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

[issue32493] UUID Module - FreeBSD build failure

[STINNER Victor]

STINNER Victor  added the comment:

Thank you Serhiy Storchaka for the fix! If someone cares about AIX, please open 
a different issue. (AIX has other more important functions that you be fixed, 
IHMO.)

--
resolution:  -> fixed
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

[issue32458] test_asyncio: test_start_tls_server_1() fails randomly

[Yury Selivanov]

Yury Selivanov  added the comment:

Not at my computer right now, can do it tomorrow.

--

___
Python tracker 

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

[issue32493] UUID Module - FreeBSD build failure

[miss-islington]

miss-islington  added the comment:


New changeset 5734f41a9b46b4fd65b6ba90240b108f8a0b7c57 by Miss Islington (bot) 
in branch '3.7':
bpo-32493: Fix uuid.uuid1() on FreeBSD. (GH-7099)
https://github.com/python/cpython/commit/5734f41a9b46b4fd65b6ba90240b108f8a0b7c57


--
nosy: +miss-islington

___
Python tracker 

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

[issue33615] test__xxsubinterpreters crashed on x86 Gentoo Refleaks 3.x

[Ned Deily]

Ned Deily  added the comment:

Victor:

>It would be nice to fix this bug before Python 3.7.0 final: either skip the 
>test, or fix it.

These tests (and failures) are only on master / 3.x, not 3.7, right?  If so, 
they have no bearing on 3.7.0.

--
nosy: +ned.deily
priority: deferred blocker -> 

___
Python tracker 

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

[issue32458] test_asyncio: test_start_tls_server_1() fails randomly

[STINNER Victor]

STINNER Victor  added the comment:

> I'm OK to skip it for now. Writing functional tests is super hard because 
> some buildbots are super slow and unpredictable.

Would you mind to write a PR to skip the PR? So you will feel guilty and will 
try to remind to fix it!

--

___
Python tracker 

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

[issue32458] test_asyncio: test_start_tls_server_1() fails randomly

[Yury Selivanov]

Yury Selivanov  added the comment:

I'm OK to skip it for now. Writing functional tests is super hard because some 
buildbots are super slow and unpredictable.

--

___
Python tracker 

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

[issue32458] test_asyncio: test_start_tls_server_1() fails randomly

[STINNER Victor]

STINNER Victor  added the comment:

It would be nice to fix this bug before Python 3.7.0 final: either skip the 
test, or fix it. Flaky tests can be very annoying. For example, the full test 
suite is run to build a Red Hat package. If a single test fails, the package 
build fails and should be retried whereas it's slow.

I understood that fixing the root cause might require to rewrite the test, so I 
don't expect a quick fix on this test. The issue is open since last December... 
Maybe we can skip the test but fix it in Python 3.7.1?

--
priority: high -> deferred blocker

___
Python tracker 

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

Re: List replication operator

[Paul]

How would one make a multi-dimensional list now, with truly-separate sub
lists?  Is there just no way to do it with the replication operator? IE,
would I just have to do
  X = [[], [], [], [], []]

or perhaps write a function to insert new sub lists into a list, or...?

 Thanks

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

[issue33615] test__xxsubinterpreters crashed on x86 Gentoo Refleaks 3.x

[STINNER Victor]

STINNER Victor  added the comment:

It would be nice to fix this bug before Python 3.7.0 final: either skip the 
test, or fix it.

Since the functions are still private, skipping a single test (until it's 
fixed) should be fine.

--
priority: normal -> deferred blocker

___
Python tracker 

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

convert a string to a variable

[bruceg113355]

I am trying to convert a string to a variable.

I got cases 1 & 2 to work, but not cases 3 & 4.

The print statement in cases 3 & 4 reports the following:
builtins.AttributeError: type object 'animal' has no attribute 'tiger'

I am stuck on creating variables that can be accessed as follows.
  animal.tiger
  self.animal.tiger

Any suggestions?

Thanks,
Bruce


# Tested on Python 3.6.5

# Case 1: This works
indata = 'animal_tiger'
vars()[indata] = "Tigers, big and strong!"
print (animal_tiger)


# Case 2: This works
class animal():
def create (self, indata):
vars(self)[indata] = "Tigers, big and strong!"
print (self.animal_tiger)

tmp = animal()
tmp.create('animal_tiger')


#

# Case 3: This does not work
indata = 'animal.tiger'
vars()[indata] = "Tigers, big and strong!"
print (animal.tiger)


#Case 4: This does not work
class animal():
def create (self, indata):
vars(self)[indata] = "Tigers, big and strong!"
print (self.animal.tiger)

tmp = animal()
tmp.create('animal.tiger')











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

[issue22703] Idle Code Context: separate changing current and future editors

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Cheryl, you are right.  The extension-feature conversion made this issue mostly 
obsolete.  Editors start without code context and the menu only toggles the 
current window.

If I had thought about it, I would have closed this or added an update last 
fall.  And I should have retested this yesterday.  The differences from what I 
proposed above are more or less intentional.  So don't write a patch until we 
agree on a list of changes.

I re-read #17535, msg225416, 2014-08-16 17:18, where this started, but not the 
discussions on the tracker and PR about the conversion details.
---

MENU has no checkmark: I noted on msg225416 that the checkmark never indicated 
the current state of the current window and that there was hardly any need to 
keep it and change its meaning, because the current state of the current window 
is plainly visible.  I am currently inclined to leave it off.  Instead, I would 
like to prefix 'Code Context' with 'Toggle'.  What do you think?  Whatever we 
do would be a precedent for other local options, such as a line number toggle, 
both on this menu and a context menu.

Since the effect of 'Code Context' is only local and not global, there should 
at least be a line separator after the global settings entry.  I might even 
like a dummy entry such as 'Current window:' after the line.

Local options should also be on the right-click context menu.  Based on my 
experience with using breakpoints, I want to try replacing the current line 
options 'Set Breakpoint' and 'Clear Breakpoint' with 'Toggle Breakpoint'.  
'Toggle Code Context' would go with this.  
---

Initial presence of CC in new windows: config-extensions.def has
  [CodeContext]
  numlines= 3
  visible= False
'numlines' is read and used.  'visible' is ignored.  To be sure, I added 
'visible=True' to config-extensions.cfg and it made no difference.

To enable CC defaulting to on for new editors, we would add a checkbox "[ ] 
Initially Visible" after the "Context lines   [ ]" box on the General tab, much 
like the "[ ] Bell on Mismatch" above on the same tab.  Saving changes would be 
the same.  The added wiring would be a bit different.

This would not be re-enabling anything that properly worked before the 
conversion.  One had to enable the feature, turn on 'visible' and then either 
never use the toggle or go back through the dialog to turn on 'visible' after 
the toggle turned it off.  Then, once one had CC running, there was the 
tradeoff between too many blank lines and too few real context lines.  I 
suspect most people left CC disabled even after trying it out.

I don't feel it a rush to add this option until it is plausibly something 
someone might do.  The aim of #33610 is to make this be true.  In any case, 
this might be better as a PR separate from fiddling with the menus.


I intentionally did not say 're-enable' 
As I remember, I did not do this because I could not believe that much of 
anyone was intentionally setting visible=True, at least for very long.  using 
this option.  Having too many blank lines



Open editor, no cc. Toggle, cc. Open another editor, no cc.


Close IDLE.  Add the following .idlerc/config-extensions.cff.
[CodeContext]
visible= True
OpenIDLE, open editor, no cc.

--

___
Python tracker 

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

[issue32493] UUID Module - FreeBSD build failure

[miss-islington]

Change by miss-islington :


--
pull_requests: +6743

___
Python tracker 

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

[issue32493] UUID Module - FreeBSD build failure

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 17d8830312d82e7de42ab89739b0771f712645ff by Victor Stinner 
(Serhiy Storchaka) in branch 'master':
bpo-32493: Fix uuid.uuid1() on FreeBSD. (GH-7099)
https://github.com/python/cpython/commit/17d8830312d82e7de42ab89739b0771f712645ff


--

___
Python tracker 

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

Re: List replication operator

[Cameron Simpson]

On 24May2018 18:17, Steven D'Aprano  
wrote:

Python has a sequence replication operator:

py> [1, 2]*3
[1, 2, 1, 2, 1, 2]

Unfortunately, it is prone to a common "gotcha":

py> x = [[]]*5  # make a multi-dimensional list
py> x
[[], [], [], [], []]
py> x[0].append(1)
py> x
[[1], [1], [1], [1], [1]]

The reason for this behaviour is that * does not copy the original list's
items, it simply replicates the references to the items. So we end up
with a new list containing five references to the same inner list.

This is not a bug and changing the behaviour is not an option.

But what do people think about proposing a new list replication with copy
operator?

   [[]]**5

would return a new list consisting of five shallow copies of the inner
list.


I think I'm against it.

Shallow copies are just as easy to get wrong, for much the same reason that * 
can produce a surprise.


So to me this introduces a new operator without much benefit, and possibly 
negative side effects (bcause it makes makes choosing an approach to sequence 
replication harder: which form should I use, per case)? The * is faster while 
the ** is safer... in very limited contexts.


I would rather there were just one model of this replication, and the model we 
have is simple and direct, with exactly the same pitfalls and benefits as 
Python's function parameter default values. So people already need this issue 
in mind to work in the language.


I'm also against the "**" spelling I find, for much the same reasons that 
people oppose allowing "=" and "==" in the same syntactic location: they're 
easy to get wrong through typing inaccuracy.


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

Re: Some Issues on Tagging Text

[Cameron Simpson]

First up, thank you for a well described problem! Remarks inline below.

On 24May2018 03:13, Subhabrata Banerjee  wrote:

I have a text as,

"Hawaii volcano generates toxic gas plume called laze PAHOA: The eruption of Kilauea volcano in Hawaii sparked new 
safety warnings about toxic gas on the Big Island's southern coastline after lava began flowing into the ocean and 
setting off a chemical reaction. Lava haze is made of dense white clouds of steam, toxic gas and tiny shards of 
volcanic glass. Janet Babb, a geologist with the Hawaiian Volcano Observatory, says the plume "looks innocuous, 
but it's not." "Just like if you drop a glass on your kitchen floor, there's some large pieces and there are 
some very, very tiny pieces," Babb said. "These little tiny pieces are the ones that can get wafted up in 
that steam plume." Scientists call the glass Limu O Pele, or Pele's seaweed, named after the Hawaiian goddess of 
volcano and fire"

and I want to see its tagged output as,

"Hawaii/TAG volcano generates toxic gas plume called laze PAHOA/TAG: The eruption of Kilauea/TAG volcano/TAG in 
Hawaii/TAG sparked new safety warnings about toxic gas on the Big Island's southern coastline after lava began flowing 
into the ocean and setting off a chemical reaction. Lava haze is made of dense white clouds of steam, toxic gas and 
tiny shards of volcanic glass. Janet/TAG Babb/TAG, a geologist with the Hawaiian/TAG Volcano/TAG Observatory/TAG, says 
the plume "looks innocuous, but it's not." "Just like if you drop a glass on your kitchen floor, there's 
some large pieces and there are some very, very tiny pieces," Babb/TAG said. "These little tiny pieces are 
the ones that can get wafted up in that steam plume." Scientists call the glass Limu/TAG O/TAG Pele/TAG, or Pele's 
seaweed, named after the Hawaiian goddess of volcano and fire"

To do this I generally try to take a list at the back end as,

Hawaii
PAHOA
Kilauea
volcano
Janet
Babb
Hawaiian
Volcano
Observatory
Babb
Limu
O
Pele

and do a simple code as follows,

def tag_text():
   corpus=open("/python27/volcanotxt.txt","r").read().split()
   wordlist=open("/python27/taglist.txt","r").read().split()


You might want use this to compose "wordlist":

wordlist=set(open("/python27/taglist.txt","r").read().split())

because it will make your "if word in wordlist" test O(1) instead of O(n), 
which will matter later if your wordlist grows.



   list1=[]
   for word in corpus:
   if word in wordlist:
   word_new=word+"/TAG"
   list1.append(word_new)
   else:
   list1.append(word)
   lst1=list1
   tagged_text=" ".join(lst1)
   print tagged_text

get the results and hand repair unwanted tags Hawaiian/TAG goddess of 
volcano/TAG.
I am looking for a better approach of coding so that I need not spend time on 
hand repairing.


It isn't entirely clear to me why these two taggings are unwanted. Intuitively, 
they seem to be either because "Hawaiian goddess" is a compound term where you 
don't want "Hawaiian" to get a tag, or because "Hawaiian" has already received 
a tag earlier in the list. Or are there other criteria.


If you want to solve this problem with a programme you must first clearly 
define what makes an unwanted tag "unwanted".


For example, "Hawaiian" is an adjective, and therefore will always be part of a 
compound term.


Can you clarify what makes these taggings you mention "unwanted"?

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

[issue33639] Use high-performance os.sendfile() in shutil.copy*

[STINNER Victor]

STINNER Victor  added the comment:

> I'm a bit depressed by the number of issues here that have a good patch 
> waiting to be merged, or even read, and that languish for years.

I'm really sorry about that. We, core developers, are doing our best, but we 
are 34 active core developers who merged 5000 pull requests in 1 year. We don't 
scale well :-(

We are working on getting more people onboard.

--

___
Python tracker 

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

[issue33640] uuid: endian of the bytes argument is not documented

[STINNER Victor]

STINNER Victor  added the comment:

At least, the UUID.bytes *attribute* is documented as using big endian:
https://docs.python.org/dev/library/uuid.html#uuid.UUID.bytes

--

___
Python tracker 

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

[issue33629] test_importlib creates a coredump on AMD64 FreeBSD 10.x Shared 3.7

[STINNER Victor]

Change by STINNER Victor :


--
resolution:  -> fixed
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

[issue33354] Python2: test_ssl fails on non-ASCII path

[STINNER Victor]

STINNER Victor  added the comment:

Thanks Pablo for your fix!

--
resolution:  -> fixed
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

[issue33354] Python2: test_ssl fails on non-ASCII path

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 19f6bd06af3c7fc0db5f96878aaa68f5589ff13e by Victor Stinner (Pablo 
Galindo) in branch '2.7':
bpo-33354: Fix test_ssl when a filename cannot be encoded (GH-6613)
https://github.com/python/cpython/commit/19f6bd06af3c7fc0db5f96878aaa68f5589ff13e


--

___
Python tracker 

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

[issue33641] Add links to RFCs

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
keywords: +patch
pull_requests: +6742
stage:  -> patch review

___
Python tracker 

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

[issue33639] Use high-performance os.sendfile() in shutil.copy*

[desbma]

desbma  added the comment:

Honestly, whatever gets this thing moving forward is good with me.

I'm a bit depressed by the number of issues here that have a good patch waiting 
to be merged, or even read, and that languish for years.

I haven't read your patch in detail, but if others agree that it is better than 
mine and can be merged, let's do it.

--

___
Python tracker 

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

[issue33641] Add links to RFCs

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

The proposed PR replaces "RFC XYZ" with ":rfc:`XYZ`". This adds hyperlinks to 
RFC documents. Actually 85% of all RFC references already use this markup, the 
PR change the rest 15% written as plain text.

--
assignee: docs@python
components: Documentation
messages: 317629
nosy: docs@python, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add links to RFCs
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue25156] shutil.copyfile should internally use os.sendfile when possible

[STINNER Victor]

STINNER Victor  added the comment:

Different implementation: bpo-33639.

--
nosy: +vstinner

___
Python tracker 

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

[issue33639] Use high-performance os.sendfile() in shutil.copy*

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

Oh! I got confused by the fact that #25063 was rejected due to concerns about 
copyfileobj() otherwise I would have commented on your patch which I totally 
missed. Yes, this overlaps with #25156 patch but it uses the same logic of 
socket.sendfile() which IMO is more robust. If you agree I'd close #25156 and 
continue in here, and I'm more than happy to co-author the contribution if 
that's OK with you.

--

___
Python tracker 

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

[issue33640] uuid: endian of the bytes argument is not documented

[STINNER Victor]

New submission from STINNER Victor :

I don't understand what is the endian of the 'bytes' parameter of the uuid.UUID 
constructor:
https://docs.python.org/dev/library/uuid.html#uuid.UUID

According to examples, it seems like the endian is big endian, but I'm not sure.

Related issue: bpo-32493.

--
assignee: docs@python
components: Documentation
messages: 317626
nosy: docs@python, vstinner
priority: normal
severity: normal
status: open
title: uuid: endian of the bytes argument is not documented
versions: Python 2.7, Python 3.6, Python 3.7

___
Python tracker 

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

[issue32374] Document that m_traverse for multi-phase initialized modules can be called with m_state=NULL

[miss-islington]

miss-islington  added the comment:


New changeset fc0356d2a34719df517a5056bf1a3709850776cf by Miss Islington (bot) 
in branch '3.6':
bpo-33629: Prevent coredump in test_importlib (GH-7090)
https://github.com/python/cpython/commit/fc0356d2a34719df517a5056bf1a3709850776cf


--

___
Python tracker 

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

[issue33629] test_importlib creates a coredump on AMD64 FreeBSD 10.x Shared 3.7

[miss-islington]

miss-islington  added the comment:


New changeset fc0356d2a34719df517a5056bf1a3709850776cf by Miss Islington (bot) 
in branch '3.6':
bpo-33629: Prevent coredump in test_importlib (GH-7090)
https://github.com/python/cpython/commit/fc0356d2a34719df517a5056bf1a3709850776cf


--

___
Python tracker 

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

[issue33354] Python2: test_ssl fails on non-ASCII path

[STINNER Victor]

STINNER Victor  added the comment:

Oh. I approved the PR but it's not merged yet :-/

--

___
Python tracker 

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

[issue33639] Use high-performance os.sendfile() in shutil.copy*

[desbma]

desbma  added the comment:

Duplicate of https://bugs.python.org/issue25156 ?

--

___
Python tracker 

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

[issue32374] Document that m_traverse for multi-phase initialized modules can be called with m_state=NULL

[miss-islington]

miss-islington  added the comment:


New changeset d9eb22c67c38b45764dd924801c72092770d200f by Miss Islington (bot) 
in branch '3.7':
bpo-33629: Prevent coredump in test_importlib (GH-7090)
https://github.com/python/cpython/commit/d9eb22c67c38b45764dd924801c72092770d200f


--

___
Python tracker 

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

[issue33629] test_importlib creates a coredump on AMD64 FreeBSD 10.x Shared 3.7

[miss-islington]

miss-islington  added the comment:


New changeset d9eb22c67c38b45764dd924801c72092770d200f by Miss Islington (bot) 
in branch '3.7':
bpo-33629: Prevent coredump in test_importlib (GH-7090)
https://github.com/python/cpython/commit/d9eb22c67c38b45764dd924801c72092770d200f


--
nosy: +miss-islington

___
Python tracker 

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

[issue31453] Debian Sid/Buster: Cannot enable TLS 1.0/1.1 with PROTOCOL_TLS

[Kurt Roeckx]

Kurt Roeckx  added the comment:

The effect is the same as calling SSL_CTX_set_min_proto_version().

--

___
Python tracker 

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

[issue31453] Debian Sid/Buster: Cannot enable TLS 1.0/1.1 with PROTOCOL_TLS

[Christian Heimes]

Christian Heimes  added the comment:

Thanks Kurt,

which API are you using to disable TLS 1.0 and 1.1? Is it the old 
SSL_CTX_set_options() or the new SSL_CTX_set_min/max_proto_version() API?

--

___
Python tracker 

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

[issue33622] Fix errors handling in the garbage collector

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 9044cd675902b438bc500908e410382ff48299d8 by Serhiy Storchaka in 
branch '2.7':
[2.7] bpo-33622: Fix issues with handling errors in the GC. (GH-7078) (#7096)
https://github.com/python/cpython/commit/9044cd675902b438bc500908e410382ff48299d8


--

___
Python tracker 

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

[issue32374] Document that m_traverse for multi-phase initialized modules can be called with m_state=NULL

[STINNER Victor]

STINNER Victor  added the comment:

MultiPhaseExtensionModuleTests.test_bad_traverse() of 
Lib/test/test_importlib/extension/test_loader.py runs the following code:
---
import importlib.util as util
spec = util.find_spec('_testmultiphase')
spec.name = '_testmultiphase_with_bad_traverse'
m = spec.loader.create_module(spec)
---

And then check that the Python "failed": that the exit code is non-zero...

That's a weak test: if the script fails before calling 
spec.loader.create_module(), the test also pass. If the function raises an 
exception but don't crash, the test pass as well.

More generally, I'm not sure about the idea of making sure that doing bad stuff 
with traverse does crash. What is the purpose of the test?

In the meanwhile, I fixed bpo-33629 by adding 
test.support.SuppressCrashReport().

I'm not asking to do something. Maybe it's fine to keep the current test.

--

___
Python tracker 

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

[issue32374] Document that m_traverse for multi-phase initialized modules can be called with m_state=NULL

[miss-islington]

Change by miss-islington :


--
pull_requests: +6741

___
Python tracker 

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

[issue33629] test_importlib creates a coredump on AMD64 FreeBSD 10.x Shared 3.7

[miss-islington]

Change by miss-islington :


--
pull_requests: +6740

___
Python tracker 

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

[issue32374] Document that m_traverse for multi-phase initialized modules can be called with m_state=NULL

[miss-islington]

Change by miss-islington :


--
pull_requests: +6739

___
Python tracker 

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

[issue33629] test_importlib creates a coredump on AMD64 FreeBSD 10.x Shared 3.7

[miss-islington]

Change by miss-islington :


--
pull_requests: +6738

___
Python tracker 

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

[issue32374] Document that m_traverse for multi-phase initialized modules can be called with m_state=NULL

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 483000e164ec68717d335767b223ae31b4b720cf by Victor Stinner in 
branch 'master':
bpo-33629: Prevent coredump in test_importlib (GH-7090)
https://github.com/python/cpython/commit/483000e164ec68717d335767b223ae31b4b720cf


--

___
Python tracker 

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

[issue33629] test_importlib creates a coredump on AMD64 FreeBSD 10.x Shared 3.7

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 483000e164ec68717d335767b223ae31b4b720cf by Victor Stinner in 
branch 'master':
bpo-33629: Prevent coredump in test_importlib (GH-7090)
https://github.com/python/cpython/commit/483000e164ec68717d335767b223ae31b4b720cf


--

___
Python tracker 

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

[issue33612] Assertion failure in PyThreadState_Clear

[STINNER Victor]

STINNER Victor  added the comment:

> Thank you for fixing this Victor!

You're welcome. It's always a pleasure to remove code!

--

___
Python tracker 

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

[issue33639] Use high-performance os.sendfile() in shutil.copy*

[Giampaolo Rodola']

Change by Giampaolo Rodola' :


--
keywords: +patch
pull_requests: +6737

___
Python tracker 

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

[issue33639] Use high-performance os.sendfile() in shutil.copy*

[Giampaolo Rodola']

New submission from Giampaolo Rodola' :

This is a follow up of #25063 and similar to socket.sendfile() (#17552). It 
provides a 20/25% speedup when copying files with shutil.copyfile(), 
shutil.copy() and shutil.copy2(). Differently from #25063 this is used for 
filesystem files only and copyfileobj() is left alone.

Unmerged #26826 is also related to this. I applied #26826 patch and built a 
wrapper around copy_file_range() and the speedup is basically the same. 
Nevertheless, even when #26826 gets merged it probably makes sense to rely on 
sendfile() in case copy_file_range() is not available (it was introduced in 
2016) or the UNIX platform supports file-to-file copy via sendfile(2) (even 
though I'm not aware of any, so this would basically be Linux-only).

Some benchmarks:

$ dd if=/dev/urandom of=/tmp/f1 bs=1K count=128
$ time ./python -m timeit -s 'import shutil; p1 = "/tmp/f1"; p2 = 
"/tmp/f2"' 'shutil.copyfile(p1, p2)'

128K copy
=

--- without patch:

2000 loops, best of 5: 160 usec per loop

real0m2.353s
user0m0.454s
sys 0m1.435s

--- with patch:

2000 loops, best of 5: 187 usec per loop

real0m2.724s
user0m0.627s
sys 0m1.634s

8MB copy


$ dd if=/dev/urandom of=/tmp/f1 bs=1M count=8

--- without patch:

50 loops, best of 5: 9.51 msec per loop

real0m3.392s
user0m0.343s
sys 0m2.478s

--- with patch:

50 loops, best of 5: 7.75 msec per loop

real0m2.878s
user0m0.105s
sys 0m2.187s

512MB copy
==

--- without patch:

1 loop, best of 5: 872 msec per loop

real0m5.574s
user0m0.402s
sys 0m3.115s

--- with patch:

1 loop, best of 5: 646 msec per loop

real0m5.475s
user0m0.037s
sys 0m2.959s

--
components: Library (Lib)
messages: 317611
nosy: StyXman, desbma, facundobatista, giampaolo.rodola, martin.panter, 
ncoghlan, neologix, petr.viktorin, python-dev, r.david.murray, vstinner
priority: normal
severity: normal
stage: patch review
status: open
title: Use high-performance os.sendfile() in shutil.copy*
type: performance
versions: Python 3.8

___
Python tracker 

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

[issue33634] Buildbot configuration issue on Windows7 buildbots

[Zachary Ware]

Zachary Ware  added the comment:

This was fixed by https://github.com/python/buildmaster-config/pull/36

--
resolution:  -> fixed
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

[issue31453] Debian Sid/Buster: Cannot enable TLS 1.0/1.1 with PROTOCOL_TLS

[Kurt Roeckx]

Kurt Roeckx  added the comment:

Note that the version in experimental only supports TLS 1.2 and 1.3 with the 
default config. It's moved from fixed in the code, to the default config file. 
I expect to upload that to unstable "soon", at which point people will be 
affected by this again.

--
nosy: +kroeckx

___
Python tracker 

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

Re: List replication operator

[MRAB]

On 2018-05-24 20:12, Ned Batchelder wrote:

On 5/24/18 2:17 PM, Steven D'Aprano wrote:

Python has a sequence replication operator:

py> [1, 2]*3
[1, 2, 1, 2, 1, 2]


Unfortunately, it is prone to a common "gotcha":

py> x = [[]]*5  # make a multi-dimensional list
py> x
[[], [], [], [], []]
py> x[0].append(1)
py> x
[[1], [1], [1], [1], [1]]


The reason for this behaviour is that * does not copy the original list's
items, it simply replicates the references to the items. So we end up
with a new list containing five references to the same inner list.


This is not a bug and changing the behaviour is not an option.

But what do people think about proposing a new list replication with copy
operator?

 [[]]**5

would return a new list consisting of five shallow copies of the inner
list.


Why "**"? Why not "@"?

[[]] @ 5


"shallow" will be the next problem.  Do we also need this?:

      [[[]]]***5 # j/k

I suppose the choice should be limited to 2 options: shallow copy and 
deep copy.

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

[issue22703] Idle Code Context: separate changing current and future editors

[Terry J. Reedy]

Terry J. Reedy  added the comment:

[In #33610, msg317601, Cheryl Sabella wrote, copying here:]

I've started looking at #22703, more specifically, I've been trying to recreate 
it.  Since the config changes in 3.6/3.7 where the flag was removed from config 
dialog, the code context needs to be turned on explicitly for each editor.  3.5 
has the old behavior.

So, I think the current change would be to add it back to config but with the 
behavior defined in #22703.  

I hope to have a PR within the next few days.

[ I will respond in a new message after investigating the current situation, 
versus 3 1/2 years ago.]

--
nosy: +cheryl.sabella
versions: +Python 3.8

___
Python tracker 

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

[issue33638] condition lock not re-acquired

[christof]

christof  added the comment:

In my previous comment, what I want to implement is not a timeout for a task to 
complete but more precisely a timeout triggered if the coroutine was not wake 
up by a notify on the condition.

--

___
Python tracker 

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

[issue33629] test_importlib creates a coredump on AMD64 FreeBSD 10.x Shared 3.7

[Brett Cannon]

Change by Brett Cannon :


--
nosy: +ncoghlan, petr.viktorin

___
Python tracker 

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

[issue30773] async generator receives wrong value when shared between coroutines

[Yury Selivanov]

Yury Selivanov  added the comment:

Thanks, I'll look into adding ag_running properly.

--

___
Python tracker 

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

[issue33355] Windows 10 buildbot: 15 min timeout on test_mmap.test_large_filesize()

[David Bolen]

David Bolen  added the comment:

For my buildbots, I suspect win8/win10 should be ok at this point.  Among any 
other changes their local disk appears to be an SSD now, which makes a big 
difference.  I observed steady 250-300MB/s write I/O for the duration of the 
mmap test, for example, so no wonder that test highlights any I/O bottlenecks.  

Those two buildbots are independent so it's more a question of running the 
tests at all versus just on one.

On the other hand, win7/winxp compete on the same host, with traditional disks. 
 So including winxp as a slow windows build together with win7 couldn't hurt, 
although as 2.7 only, winxp runs far fewer tests nowadays.

--

___
Python tracker 

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

Re: List replication operator

[Ned Batchelder]

On 5/24/18 2:17 PM, Steven D'Aprano wrote:

Python has a sequence replication operator:

py> [1, 2]*3
[1, 2, 1, 2, 1, 2]


Unfortunately, it is prone to a common "gotcha":

py> x = [[]]*5  # make a multi-dimensional list
py> x
[[], [], [], [], []]
py> x[0].append(1)
py> x
[[1], [1], [1], [1], [1]]


The reason for this behaviour is that * does not copy the original list's
items, it simply replicates the references to the items. So we end up
with a new list containing five references to the same inner list.


This is not a bug and changing the behaviour is not an option.

But what do people think about proposing a new list replication with copy
operator?

 [[]]**5

would return a new list consisting of five shallow copies of the inner
list.


"shallow" will be the next problem.  Do we also need this?:

    [[[]]]***5 # j/k

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

[issue30773] async generator receives wrong value when shared between coroutines

[Nathaniel Smith]

Nathaniel Smith  added the comment:

My thoughts: https://bugs.python.org/issue32526#msg309783

--

___
Python tracker 

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

[issue33638] condition lock not re-acquired

[christof]

New submission from christof :

Hello,

I have a simple code which triggers a timeout if a task did not complete

import asyncio

async def task_timeout():
condition = asyncio.Condition()
with await condition:
try:
await asyncio.wait_for(condition.wait(), timeout=4)
except asyncio.TimeoutError as e:
 
print("timeout reached")
# uncomment this line to make the code work
# await asyncio.sleep(0)


f = asyncio.ensure_future(task_timeout())

loop= asyncio.get_event_loop()
loop.run_until_complete(f)

It throws an exception when leaving the scope for the condition because it 
expects the lock to be acquired:

RuntimeError: Lock is not acquired.

If you uncomment the line to sleep, it will work because it will continue in 
the coroutine Condition.wait and call:
 yield from self.acquire() => locks.py line 355

I think this is a bug and that this behaviour is not the expected one.

--
components: asyncio
messages: 317604
nosy: asvetlov, christof, yselivanov
priority: normal
severity: normal
status: open
title: condition lock not re-acquired
type: behavior
versions: Python 3.6

___
Python tracker 

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

[issue30773] async generator receives wrong value when shared between coroutines

[Yury Selivanov]

Change by Yury Selivanov :


--
assignee:  -> yselivanov
components: +Interpreter Core -asyncio
priority: normal -> high
versions: +Python 3.8

___
Python tracker 

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

[issue30773] async generator receives wrong value when shared between coroutines

[Yury Selivanov]

Yury Selivanov  added the comment:

Thanks Jan. Thanks a lot for a short script to reproduce this bug.

The actual problem here is that asynchronous generators don't control their 
'asend' and 'athrow' coroutines in any way. So if you have two of them 
iterating *in parallel* they will cause their asynchronous generator to be in 
an inconsistent state.

The most obvious solution to this problem is to prohibit iterating 
'asend'/'athrow' objects in parallel by throwing an exception.  

Nathaniel, what are your thoughts on this?

--
nosy: +njs

___
Python tracker 

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

[issue33623] Fix possible SIGSGV when asyncio.Future is created in __del__

[Yury Selivanov]

Yury Selivanov  added the comment:

> Then we should find what callable is NULL and fix the place where it is 
> called. _PyObject_FastCallDict() should never be called with NULL.

My understanding is that the interpreter is being shutdown and half of the 
objects are freed. We're still holding a reference to *something* in Python 
space and try calling it.  The obvious fix for that is simply avoid capturing 
tracebacks if a Future object is created during finalization of the interpreter 
(it's pointless to capture it anyways at that point).

--

___
Python tracker 

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