Re: cProfile, timed call tree

[dieter]

Nico Schlömer  writes:

> From what I understand about the Python profilers, the type of information
> you get from a stats object is
>
>   * How much time was spent in function X,
>   * what the callers and callees of function X are, and
>   * and bunch of meta info about function X.
>
> With the program
> ```
> def prime(n):
> # compute the n-th prime number, takes longer for larger n
> return 2
>
> def a():
> return prime(1)
>
> def b():
> return prime(4000)
>
> a()
> b()
> ```
> I would be able to find that `prime` took a lot of time, but not that it
> took more time when called from `b()`. In other words: I cannot construct
> the call tree with times from Stats.

You will see that "prime" was called both from "a" and "b" - and
*in this particular case*, you will see that the execution times
of "b" and "prime" are almost identical and derive that the "prime"
call of b was the expensive one.

But, in general, you are right: you cannot reconstruct complete
call trees. The reason is quite simple: maintaining information
for the complete caller ancestry (rather than just the immediate
caller) is expensive (both in terms of runtime and storage).
Profiling usually is used as a preparation for optimization.
Optimization has the greatest effects if applied to inner loops.
And for the analysis of inner loops, complete call tree information
is not necessary.

> Is this correct? If not, how to get a timed call tree from Stats? Perhaps
> that's not the right think to work with?

You will need to write your own profiler - one that keeps track
not only about the immediate caller of a function call but
of the whole caller ancestry (maybe recursion reduced).

You can see an example of a custom profiler
in "Products.ZopeProfiler" (--> PyPI).
It does not take into account the whole caller ancestry.
Instead it records additional information concerning higher level
Zope (a Web application framework) calls.

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

Re: Raw string statement (proposal)

[Mikhail V]

On Fri, May 25, 2018 at 1:15 PM, bartc  wrote:
> On 25/05/2018 05:34, Mikhail V wrote:
>

> I had one big problem with your proposal, which is that I couldn't make head
> or tail of your syntax. Such a thing should be immediately obvious.
>
> (In your first two examples, what IS the exact string that you're trying to
> incorporate? That is not clear at all.)

You re right, this part is not very clear.
I was working on syntax mainly, but the document is getting better.
I make constant changes to it, here is a link on github:

https://github.com/Mikhail22/Documents/blob/master/raw-strings.rst


> One problem here is how to deal with embedded non-printable characters: CR,
> LF and TAB might become part of the normal source text, but how about
> anything else? Or would you only allow text that might appear in a text file
> where those characters would also cause issues?

This syntax does not imply anything about text. From the editor's POV
it's just the same as it is now - you can insert anything in a .py file.
So it does not add new cases to current state of affairs in this regard.
But maybe I'm not completely understand your question.



> Another thing that might come up: suppose you do come up with a workable
> scheme, and have a source file PROG1.PY which contains such raw strings.
>
> Would it then be possible to create a source file PROG2.PY which contains
> PROG1.PY as a raw string? That is, without changing the text from PROG1.PY
> at all.

Should be fine, with only difference that you must
indent the PROG1.PY if it will be placed inside an indented suite.
I was thinking about this nuance - I've added a special case for this
in addition to the ? flag.

data >>> X"#tag"
...
#tag

It will treat the block "as is", namely grab everythin together with indents,
like in TQS. This may cover some edge-cases.


> Here's one scheme I use in another language:
>
>print strinclude "file.txt"
>
> 'strinclude "file.txt"' is interpreted as a string literal which contains
> the contents of file.txt, with escapes used as needed. In fact it can be
> used for binary files too.
> [...]
> As for a better proposal, I'm inclined not to make it part of the language
> at all, but to make it an editor feature: insert a block of arbitrary text,
> and give a command to turn it into a string literal. With perhaps another
> command to take a string literal within a program and view it as un-escaped
> text.

I think it may be vice-versa - including links to external files
might be more effective approach in some sense. It only needs
some special kind of editor that would seamlessly embed them.
Though I don't know of such feature frankly speaking.
And there might be many caveats here.

And the feature to convert a text piece to Python string directly -
it is already possible in many editors - via macros or scripting.
But I think you falsely think that it is the solution to the problem.
Such changes - it's exactly what should be avoided.

In theory - an adequate feature like this (if it has real value)
will require the editor to track all manipulations - and give feedback.
You don't know when you have escaped some string or
not. And how do you save or see this events?
IOW this might be way harder to implement than the
approach with external text bits.


The simplest solution would be of course to write a translator.
For such syntax change - it is **millions** times easier than
what you've described.



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

Re: Enums: making a single enum

[Chris Angelico]

On Sat, May 26, 2018 at 3:07 PM, Ian Kelly  wrote:
> On Fri, May 25, 2018 at 11:00 PM, Chris Angelico  wrote:
>> On Sat, May 26, 2018 at 2:46 PM, Steven D'Aprano
>>  wrote:
>>> Am I silly for wanting to make a single enum?
>>>
>>> I have a three-state flag, True, False or Maybe. Is is confusing or bad
>>> practice to make a single enum for the Maybe case?
>>>
>>>
>>> from enum import Enum
>>> class State(Enum):
>>> Maybe = 2
>>>
>>> Maybe = State.Maybe
>>> del State
>>>
>>> Is there a better way of handling a three-state flag like this?
>>>
>>
>> Does it need to have a value of 2? If not:
>>
>> # Tri-state logic
>> Maybe = object()
>
> The enum has a nice __str__ though.

Ah, good point. Then sure, go with the enum - but have a comment or
docstring explaining that this is augmented with the literals True and
False.

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

Re: Enums: making a single enum

[Ian Kelly]

On Fri, May 25, 2018 at 11:00 PM, Chris Angelico  wrote:
> On Sat, May 26, 2018 at 2:46 PM, Steven D'Aprano
>  wrote:
>> Am I silly for wanting to make a single enum?
>>
>> I have a three-state flag, True, False or Maybe. Is is confusing or bad
>> practice to make a single enum for the Maybe case?
>>
>>
>> from enum import Enum
>> class State(Enum):
>> Maybe = 2
>>
>> Maybe = State.Maybe
>> del State
>>
>> Is there a better way of handling a three-state flag like this?
>>
>
> Does it need to have a value of 2? If not:
>
> # Tri-state logic
> Maybe = object()

The enum has a nice __str__ though.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Enums: making a single enum

[Chris Angelico]

On Sat, May 26, 2018 at 2:46 PM, Steven D'Aprano
 wrote:
> Am I silly for wanting to make a single enum?
>
> I have a three-state flag, True, False or Maybe. Is is confusing or bad
> practice to make a single enum for the Maybe case?
>
>
> from enum import Enum
> class State(Enum):
> Maybe = 2
>
> Maybe = State.Maybe
> del State
>
> Is there a better way of handling a three-state flag like this?
>

Does it need to have a value of 2? If not:

# Tri-state logic
Maybe = object()

Though I have to say, you picked the wrong name for the third state.
Everyone knows it should be File_Not_Found.

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

Enums: making a single enum

[Steven D'Aprano]

Am I silly for wanting to make a single enum?

I have a three-state flag, True, False or Maybe. Is is confusing or bad 
practice to make a single enum for the Maybe case?


from enum import Enum
class State(Enum):
Maybe = 2

Maybe = State.Maybe
del State




Is there a better way of handling a three-state flag like this?


-- 
Steve

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

[issue31096] asyncio.stream.FlowControlMixin._drain_helper may lead to a blocking behavior

[Dmitry Malinovsky]

Dmitry Malinovsky  added the comment:

I've changed the implementation significantly since August 2017, futures are 
not involved anymore so please ignore that part. However, such drain behavior 
is still present - but I don't think anymore that yielding to the event loop is 
an easy fix.

I've tried to do so in my lib, and it showed significant slowdowns (around 4-5k 
publishes per second). It's not acceptable. I also found this message from 
Guido https://github.com/python/asyncio/issues/263#issuecomment-142702725.

What really helped is a counter that tracks send calls without waiting for 
replies, and a user-provided limit; when the counter reaches the limit, an 
explicit yield (via await asyncio.sleep(0)) is performed. This helped to 
achieve around 15-16k publishes per second (3-4 times faster. Here's the code:
https://github.com/malinoff/amqproto/blob/6568204b539ecf820af2da11bddcca9ce7323ac5/amqproto/adapters/asyncio_adapter.py#L53-L71

Now I'm thinking that such behavior should only be documented - so library 
authors can deal with it before they face this in production. But if you have 
other thoughts, I'd be glad to hear.

--

___
Python tracker 

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

[issue33598] ActiveState Recipes links in docs, and the apparent closure of Recipes

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> I have seen no official announcement of a shutdown date for 
> the code.activestate.com website, but it's future has to be
> in question considering the migration.

We can check with ActiveState but my understanding is that they're leaving the 
existing web pages up (they already reduced the maintenance burden to zero by 
eliminating new updates so that the site wouldn't be spammed).  

So, I don't think there is a real issue here.  Also, I prefer the existing 
links because they include more than code (there is also exposition, 
commentary, history, and fork references).

--
priority: normal -> low

___
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

[Gregory Ewing]

bartc wrote:

/The/ matrix multiplication operator?

In which language? And what was wrong with "*"?


It seems you're unaware that Python *already* has an '@'
operator. It was added specifically so that numpy could
use it for matrix multiplication. A new operator was
needed because numpy already uses '*' for elementwise
multiplication.

So, the issue with @ being mistakenly marked up already
exists.

(I've implemented matrix multiply in a language (although for 
specialised matrix types), and I used the same "*" symbol as was used to 
multiply anything else.)


Before '@' was added, numpy did this as well, but it
was a pain to have to use a whole different type just to
get one operator to behave differently. Painful enough
that Guido was eventually persuaded to add a new operator.

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

Re: List replication operator

[Gregory Ewing]

Dennis Lee Bieber wrote:

@ requires use of the weaker/shorter "ring finger" on (for me) the
weaker left hand.


But... choosing an operator on that basis would be
discriminating against left-handed people!

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

Re: List replication operator

[Steven D'Aprano]

On Fri, 25 May 2018 09:58:19 -0700, Rob Gaddi wrote:

[...]
>> This is a frequent, recurring pain point. Experienced programmers
>> forget how confusing the behaviour of * is because they're so used to
>> the execution model. They forget that writing a list comp is not even
>> close to obvious, not only for beginners but even some experienced
>> Python programmers.
>> 
>> 
> I agree that it's non-obvious, but I disagree with your diagnosis.  The
> non-obvious bit is that the empty list is a reference to a newly created
> mutable, not an immutable constant.  Or, more the point, that the word
> "mutable" is one that you need to know and think about in the first
> place.

I challenge you to read this bug report and claim that the poster's error 
was to *correctly* think that [[]]*5 made five references to the same 
list, but *incorrectly* failed to realise that list.append modified the 
list in place.

https://bugs.python.org/issue33636


> class list(_list):
>@staticmethod
>def replicate(*n, fill=_nodefault, call=list):
>  """Return a list of specified dimensions.
[...]

Interesting implementation to play with, thanks.



-- 
Steve

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

[issue33647] Add re.replace(string, replacement_map)

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> I would like an example added to the sub(pattern, function, 
> string) examples.

That seems like the most reasonable way to go.

--
nosy: +rhettinger

___
Python tracker 

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

[issue33651] Add get() method to sqlite3.Row class

[Raymond Hettinger]

Raymond Hettinger  added the comment:

How is this needed?  SQL queries return rows that are homogenous and with known 
fields.  This is isn't like other dictionaries when you might not know in 
advance whether a given key is present.

--
nosy: +rhettinger

___
Python tracker 

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

[issue33521] Add 1.32x faster C implementation of asyncio.isfuture().

[Yury Selivanov]

Yury Selivanov  added the comment:

IMO this particular patch is OK and should go in.  I'll take another look at 
the PR in a few days (and will run some benchmarks myself before making the 
decision).

--

___
Python tracker 

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

[issue33521] Add 1.32x faster C implementation of asyncio.isfuture().

[STINNER Victor]

STINNER Victor  added the comment:

I disagree with your rationale. At least, it is not how we decide to
optimize something or not in Python. Python is first made of people who
will have to maintain the code for the next 5 years if not longer. C code
is harder to maintain than Python code.

A significant speedup on a microbenchmark is nice, but asyncio still lacks
a more general benchmark suite...

I have no opinion on this specific optimisation.

--

___
Python tracker 

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

Re: Some Issues on Tagging Text

[MRAB]

On 2018-05-25 23:24, Cameron Simpson wrote:
[snip]

You can reduce that list by generating the "wordlist" form from something
smaller:

   base_phrases = ["Kilauea volcano", "government of Mexico", "Hawaii"]
   wordlist = [
   (base_phrase, " ".join([word + "/TAG" for word in base_phrase.split()]))
   for base_phrase in base_phrases
   ]

You could even autosplit the longer phrases so that your base_phrases
_automatically_ becomes:

   base_phrases = ["Kilauea volcano", "Kilauea", "volcano", "government of
   Mexico", "government", "Mexico", "Hawaii"]


That list should also include "of".

As the OP doesn't want all instances of "of" to be tagged, there could 
be a separate exceptions list that contains those sub-phrases that 
should not be tagged; they would be dropped from the base_phrases list 
that was created.


[snip]
--
https://mail.python.org/mailman/listinfo/python-list

Re: Some Issues on Tagging Text

[Ben Finney]

Cameron Simpson  writes:

> On 25May2018 04:23, Subhabrata Banerjee  wrote:
> >On Friday, May 25, 2018 at 3:59:57 AM UTC+5:30, Cameron Simpson wrote:
> >> If you want to solve this problem with a programme you must first
> >> clearly define what makes an unwanted tag "unwanted". [...]
> >
> >By unwanted I did not mean anything so intricate.
> >Unwanted meant things I did not want.
>
> That much was clear, but you need to specify in your own mind
> _precisely_ what makes some things unwanted and others wanted. Without
> concrete criteria you can't write code to implement those criteria.

Importantly, “define” means more than just coming up with examples.

To determine with precision; to mark out with distinctness; to
ascertain or exhibit clearly.



Before you can write code that will *reliably* select those parts you
want and exclude those parts you don't want, you need to precisely
define what should be matched such that it also excludes what should not
be matched.

Come up with statements about what you want, and ask “if *any* text
matches this, does that necessarily mean it is wanted?”

Then do exactly the same in reverse: “if *any* text fails to match this,
does that necessarily mean it is unwanted?”

Keep refining your statement until it is precise enough that you can say
“yes” to both those questions.

Then, you have a statement that is precise enough to write tests for,
and therefore to write in code.

-- 
 \   “I have always wished for my computer to be as easy to use as |
  `\   my telephone; my wish has come true because I can no longer |
_o__)  figure out how to use my telephone.” —Bjarne Stroustrup |
Ben Finney

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

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

[Dan Stromberg]

On Thu, May 24, 2018 at 7: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')


Not what you asked, but I believe pylint recommends using not isinstance
instead of type !=.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The PIL show() method looks for the default viewer. How do I change this to a different viewer (of my choice)?

[boB Stepp]

On Fri, May 25, 2018 at 6:04 AM, Paul St George  wrote:
> I am using the Python Imaging Library (PIL), Python 2 and Raspberry Pi 3 B+
>
> My code is simply:
>
> from PIL import Image
>
> im = Image.open(‘somepic.jpg’)
> im.show() # display image
>
>
> But the show() method looks for the default viewer (probably xv). How do I
> change this (in the code, or in some settings) to a different viewer (of my
> choice)?

In the PIL docs for show() at
https://pillow.readthedocs.io/en/5.1.x/reference/Image.html#PIL.Image.Image.show
it says:


Image.show(title=None, command=None)

Displays this image. This method is mainly intended for debugging purposes.

On Unix platforms, this method saves the image to a temporary PPM
file, and calls either the xv utility or the display utility,
depending on which one can be found.

On macOS, this method saves the image to a temporary BMP file, and
opens it with the native Preview application.

On Windows, it saves the image to a temporary BMP file, and uses the
standard BMP display utility to show it (usually Paint).

Parameters:

title – Optional title to use for the image window, where possible.
command – command used to show the image


I have not had occasion to use PIL, but perhaps this command parameter
can be used to do what you want?  If not then perhaps you can write
your own function to load your image into your favorite image viewer.


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

Re: List replication operator

[Steven D'Aprano]

On Fri, 25 May 2018 13:05:01 -0400, Dennis Lee Bieber wrote:

>   Let me play devil's advocate... and propose a simple change, with 
no
> new operators...
> 
>   sl = [] * n #current behavior
>   dl = n * [] #deep copy behavior

n*[] is already supported. You will suddenly change the behaviour of any 
existing Python code that uses it, depending on which version they happen 
to use.



-- 
Steve

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

Re: List replication operator

[Steven D'Aprano]

On Sat, 26 May 2018 02:58:06 +1000, Chris Angelico wrote:

> Your mail/news client might choose to represent configure.ac as a link,
> since ".ac" is a valid TLD.

Isn't *everything* a valid TLD now?

For the right price, at least.



-- 
Steve

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

Re: Some Issues on Tagging Text

[Cameron Simpson]

On 25May2018 04:23, Subhabrata Banerjee  wrote:

On Friday, May 25, 2018 at 3:59:57 AM UTC+5:30, Cameron Simpson wrote:

On 24May2018 03:13, 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

[...]

>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()

[...]

>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". [...]


By unwanted I did not mean anything so intricate.
Unwanted meant things I did not want.


That much was clear, but you need to specify in your own mind _precisely_ what 
makes some things unwanted and others wanted. Without concrete criteria you 
can't write code to implement those criteria.


I'm not saying "you need to imagine code to match these things": you're clearly 
capable of doing that. I'm saying you need to have well defined concepts of 
what makes something unwanted (or, if that is easier to define, wanted).  You 
can do that iteratively: start with your basic concept and see how well it 
works. When those concepts don't give you the outcome you desire, consider a 
specific example which isn't working and try to figure out what additional 
criterion would let you distinguish it from a working example.



For example,
if my target phrases included terms like,
government of Mexico,

now in my list I would have words with their tags as,
government
of
Mexico

If I put these words in list it would tag
government/TAG of/TAG Mexico

but would also tag all the "of" which may be
anywhere like haze is made of/TAG dense white,
clouds of/TAG steam, etc.

Cleaning these unwanted places become a daunting task
to me.


Richard Damon has pointed out that you seem to want phrases instead of just 
words.



I have been experimenting around
wordlist=["Kilauea volcano","Kilauea/TAG 
volcano/TAG"),("Hawaii","Hawaii/TAG"),...]
tag=reduce(lambda a, kv: a.replace(*kv), wordlist, corpus)

is giving me sizeably good result but size of the wordlist is slight concern.


You can reduce that list by generating the "wordlist" form from something 
smaller:


 base_phrases = ["Kilauea volcano", "government of Mexico", "Hawaii"]
 wordlist = [
 (base_phrase, " ".join([word + "/TAG" for word in base_phrase.split()]))
 for base_phrase in base_phrases
 ]

You could even autosplit the longer phrases so that your base_phrases 

[issue33510] [logging] add JSON log formatter

[Wilfredo Sanchez]

Wilfredo Sanchez  added the comment:

Please consider using RFC 7464 (JSON Text Sequences).

This allows detection of truncated JSON events without losing the following 
event.  It allows newlines in the JSON data.

All this involves is adding an RS between events.

--
nosy: +wsanchez

___
Python tracker 

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

[issue33651] Add get() method to sqlite3.Row class

[Wilfredo Sanchez]

New submission from Wilfredo Sanchez :

The sqlite3.Row class has mapping-like behavior but does not implement the 
get() method, so providing default values in code requires a bit of boilerplate 
that is not necessary with dictionaries.

--
components: Library (Lib)
messages: 317719
nosy: wsanchez
priority: normal
severity: normal
status: open
title: Add get() method to sqlite3.Row class
type: enhancement
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

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

[Matthias Bussonnier]

Matthias Bussonnier  added the comment:

> Just to quickly touch on Matthias' question about opt-in or deprecations, a 
> key thing to note is the ast module is automatically generated from the ASDL 
> file, so either of those approaches would require developing a new mechanism 
> in the code generator to support either approach.

Yes, I was mostly thinking of `compile(..., mode, flags=PyAstOnly)` as to where 
the deprecation could be. 

Thinking a bit more about the `compile`'s `multiline` option, that would also 
be quite useful to allow some construct that are so far forbidden, like 
top-level `await`.

I'm thinking that splitting `exec` into two options:
  - `module` which could do what current 3.7 does and find docstrings plus do 
some optimisation and sanity check if necessary, prevent top-level await. 
  - `multiline` which would treat the source as a sequence of statement, allwo 
top level `await` ... etc.

this could allow both to evolve and have their individual advantage, leaving 
`exec` unchanged for legacy reasons.

--

___
Python tracker 

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

[issue33650] Prohibit adding a signal handler for SIGCHLD

[Yury Selivanov]

New submission from Yury Selivanov :

Doing that will break subprocesses.

--
components: asyncio
messages: 317717
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Prohibit adding a signal handler for SIGCHLD
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

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

[Brett Cannon]

Brett Cannon  added the comment:

Just to quickly touch on Matthias' question about opt-in or deprecations, a key 
thing to note is the ast module is automatically generated from the ASDL file, 
so either of those approaches would require developing a new mechanism in the 
code generator to support either approach.

--
nosy: +brett.cannon

___
Python tracker 

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

[issue32841] Asyncio.Condition prevents cancellation

[Bar Harel]

Bar Harel  added the comment:

Yup. Thanks Yuri :-)

--
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

[issue33598] ActiveState Recipes links in docs, and the apparent closure of Recipes

[Terry J. Reedy]

Terry J. Reedy  added the comment:

The Python Cookbook, based on the site, says that copyright of each recipe is 
retained by original authors.  If so authors who have signed the PSF CLA can 
contribute their own work.

Since Active State must have collectively licensed the recipes to O'Reilly, 
they could do the same for us.  But if Raymond is the only author concerned, 
that should not be necessary.

--
nosy:  -lemburg

___
Python tracker 

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

[issue33598] ActiveState Recipes links in docs, and the apparent closure of Recipes

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

I'd suggest to contact ActiveState first before jumping to conclusions.

--
nosy: +lemburg

___
Python tracker 

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

[issue33598] ActiveState Recipes links in docs, and the apparent closure of Recipes

[Alex Walters]

Alex Walters  added the comment:

All recipes are MIT licensed unless otherwise noted on the recipe itself.

However, AFAICT, all the recipes that are linked to in the docs are written by 
Raymond Hettinger, so I don't think licensing will be that big of an issue.  We 
know where he is, we can ask him, and he has signed a CLA.

--

___
Python tracker 

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

[issue33649] asyncio docs overhaul

[Barry A. Warsaw]

Change by Barry A. Warsaw :


--
nosy: +barry

___
Python tracker 

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

[issue33598] ActiveState Recipes links in docs, and the apparent closure of Recipes

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Can you check the copyright and license of the recipe text and code?

--
nosy: +terry.reedy

___
Python tracker 

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

[issue33647] Add re.replace(string, replacement_map)

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Your proposal is underspecified.  (And 'yours' is inconsistent with 'your';-). 
If you want sequential replacememt in multiple scans, make sequential replace 
calls.  Use a loop if the number of replacement scans is variable or large.  To 
be sure of the order of replacements, a sequence is better than a dict, but 
dict.values() instead would work in the following code.

s = 'this is my string'
for old, new in (('my', 'your'), ('string', 'car')):
s = s.replace(old, new)
print(s)

If you want parallel replacement in a single scan, a different scanner is 
required.  If the keys (search strings) are all single letters, one should use 
str.translate.  For a general string to string mapping, use re.sub with a 
replacement function that does a lookup.

import re

s = 'this is my string'
subs = {'my': 'your', 'string': 'car'}
print(re.sub('|'.join(subs), lambda m: subs[m.group(0)], s))

In any case, the proposal to modify str.replace should be rejected.

However, the re code is not completely trivial (I did not work it out until 
now), so I think it plausible to add the following to the re module.

def replace(string, map):
"""Return a string with map keys replaced by their values.

*string* is scanned once for non-overlapping occurrences of keys.
"""
return sub('|'.join(map), lambda m: map[m.group(0)], string)

I would reference this in the str.translate entry for when keys are not 
restricted to letters.

If adding replace() is rejected, I would like an example added to the 
sub(pattern, function, string) examples.

--
nosy: +serhiy.storchaka, terry.reedy
stage:  -> test needed
title: Make string.replace accept a dict instead of two arguments -> Add 
re.replace(string, replacement_map)

___
Python tracker 

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

[issue33649] asyncio docs overhaul

[Yury Selivanov]

New submission from Yury Selivanov :

An overhaul of asyncio documentation is long overdue.  Here's the structure for 
it that I have in mind:

- Introduction
(what is asyncio and async/await)

- A quick tutorial
(show how to use asyncio.run() and basic functions like asyncio.sleep() and 
teach that asyncio programs are all about async/await and *not* about callbacks 
or event loops)

- High-level APIs
(Tasks, Streams, Subprocesses, few other functions)

- Low-level APIs
  - Preface (talk a bit about everything: what's an event loop, what is a 
Future and a Transport)
  - Futures
  - Event loop APIs
  - Transports and Protocols (when to use and when not to use them)

- Tutorials
  - High-level networking server
  - HTTP application
  - Low-level protocol implementation using Transports
  - etc

--
assignee: docs@python
components: Documentation, asyncio
messages: 317709
nosy: akuchling, asvetlov, docs@python, yselivanov
priority: normal
severity: normal
status: open
title: asyncio docs overhaul
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

[issue30145] Create a How to or Tutorial documentation for asyncio

[Yury Selivanov]

Yury Selivanov  added the comment:

Closing this issue. I'll open a new one for the planned asyncio docs overhaul.

--
resolution:  -> out of date
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

[issue31647] asyncio: StreamWriter write_eof() after close raises mysterious AttributeError

[Yury Selivanov]

Yury Selivanov  added the comment:

If this issue isn't yet fixed could you please submit a PR?

--

___
Python tracker 

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

[issue31096] asyncio.stream.FlowControlMixin._drain_helper may lead to a blocking behavior

[Yury Selivanov]

Yury Selivanov  added the comment:

Andrew, what are your thoughts on this one?

--
nosy: +asvetlov
versions: +Python 3.8 -Python 3.5, Python 3.6

___
Python tracker 

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

[issue32528] Change base class for futures.CancelledError

[Yury Selivanov]

Yury Selivanov  added the comment:

Closing this issue as I, personally, don't see this happening and there's no 
point in keeping it open.

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

[issue30698] asyncio sslproto do not shutdown ssl layer cleanly

[Yury Selivanov]

Yury Selivanov  added the comment:

Is this issue resolved now, or do we need to work on this?

--

___
Python tracker 

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

[issue32672] .then execution of actions following a future's completion

[Yury Selivanov]

Yury Selivanov  added the comment:

Closing this one. I don't see us adding Future.then. Feel free to discuss on 
the MLs.

--
components: +asyncio -Library (Lib)
nosy: +asvetlov, yselivanov
resolution:  -> rejected
stage: patch review -> resolved

___
Python tracker 

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

[issue32841] Asyncio.Condition prevents cancellation

[Yury Selivanov]

Yury Selivanov  added the comment:

Should this issue be closed now?

--

___
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 18:05, Dennis Lee Bieber wrote:

On Fri, 25 May 2018 15:40:41 + (UTC), Steven D'Aprano
 declaimed the following:


On Fri, 25 May 2018 22:46:37 +1000, Chris Angelico wrote:


We've already had a suggestion for [[]]@5 and that should deal with that
issue. Steven is proposing "multiply by copying" as an alternative to
"multiply by referencing", so an alternative multiplication operator
should fit that correctly. Steve, I don't want to speak for you; can you
confirm or deny acceptance of the matmul operator as a better spelling?


I thought that ** would be less controversial than @ since that's much 
newer. Silly me.


Personally, I don't care much either way. Probably a microscopic 
preference for @ over ** since it is shorter, but not enough to matter.




@ requires use of the weaker/shorter "ring finger" on (for me) the
weaker left hand.


On my UK keyboard, @ is on the right-hand side.


** makes use of the stronger right hand, and longest finger so less a
stretch. And the timing for the second * isn't that much.


Let me play devil's advocate... and propose a simple change, with no
new operators...

sl = [] * n #current behavior
dl = n * [] #deep copy behavior

Both orders are currently valid, and do the same thing, so a change 
would break someone's code.

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

[issue1366311] SRE engine should release the GIL when/if possible

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

> Did you try to use regex which has this feature? For short strings and simple 
> patterns there may be no benefit.

In my use case, it’s not possible, since the problematic API is glob.iglob() 
through multiple levels of calls.

--

___
Python tracker 

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

[issue1366311] SRE engine should release the GIL when/if possible

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

It is possible to implement this feature, but it has some limitations.

Did you try to use regex which has this feature? For short strings and simple 
patterns there may be no benefit.

--
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka
type:  -> enhancement

___
Python tracker 

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

[issue33595] Fix references to lambda "arguments"

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Thanks for the fix.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
title: FIx references to lambda "arguments" -> Fix references to lambda 
"arguments"

___
Python tracker 

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

[issue33595] FIx references to lambda "arguments"

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset 804fcf66559992db9d23695e501c502ab20b7712 by Terry Jan Reedy in 
branch '2.7':
[2.7] bpo-33595: Fix lambda parameters being refered as arguments (GH-7037) 
(GH-7122)
https://github.com/python/cpython/commit/804fcf66559992db9d23695e501c502ab20b7712


--
nosy: +terry.reedy

___
Python tracker 

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

[issue33595] FIx references to lambda "arguments"

[Terry J. Reedy]

Change by Terry J. Reedy :


--
pull_requests: +6757

___
Python tracker 

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

[issue33645] Importing bs4 fails with -3 option in Python 2.7.15

[Florian Schulze]

Florian Schulze  added the comment:

You are right, this actually happens with Python 2.7.14 as well. I was fooled 
by a warnings.filterwarnings matching to a path in my codebase. That one did 
match for my Python 2.7.15 testing but didn't for my Python 2.7.14 testing, 
because those were done in a temporary path which didn't match. I should have 
tried to narrow it down further first.

I'm glad you found the necessary -We option.

Thanks for looking into this and for the patch!

I'm currently unable to test the patch though.

--

___
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

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

PR 7121 is based on PR 5927 and goes one step further. It doesn't introduce a 
new AST type DocString. Third-party code should not need any adaptation for 3.7.

--

___
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

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
keywords: +patch
pull_requests: +6756
stage: commit review -> patch review

___
Python tracker 

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

[issue33595] FIx references to lambda "arguments"

[miss-islington]

Change by miss-islington :


--
pull_requests: +6755

___
Python tracker 

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

[issue33595] FIx references to lambda "arguments"

[miss-islington]

Change by miss-islington :


--
pull_requests: +6754
stage: backport needed -> patch review

___
Python tracker 

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

[issue33594] add deprecation since 3.5 for a few methods of inspect.

[Terry J. Reedy]

Terry J. Reedy  added the comment:

See also #33582 for 'formatargspec'.

--
nosy: +terry.reedy, yselivanov
versions:  -Python 3.5

___
Python tracker 

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

[issue33587] inspect.getsource performs unnecessary filesystem stat call

[Terry J. Reedy]

Change by Terry J. Reedy :


--
stage:  -> patch review
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

[issue33587] inspect.getsource performs unnecessary filesystem stat call

[Terry J. Reedy]

Change by Terry J. Reedy :


--
nosy: +yselivanov
title: inspect.getsource performs unnecessary filesystem stat call which is 
ignored in some circumstances -> inspect.getsource performs unnecessary 
filesystem stat call

___
Python tracker 

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

[issue33582] formatargspec deprecated but does nto emit DeprecationWarning.

[Terry J. Reedy]

Change by Terry J. Reedy :


--
nosy: +yselivanov
versions:  -Python 3.5

___
Python tracker 

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

[issue1366311] SRE engine should release the GIL when/if possible

[Armin Rigo]

Change by Armin Rigo :


--
nosy:  -arigo

___
Python tracker 

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

[issue33573] statistics.median does not work with ordinal scale, add doc

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I agree.

--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python, terry.reedy
resolution: not a bug -> 
stage:  -> needs patch
title: statistics.median does not work with ordinal scale -> statistics.median 
does not work with ordinal scale, add doc
type: behavior -> enhancement
versions: +Python 3.6, Python 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

[Rob Gaddi]

On 05/25/2018 10:13 AM, bartc wrote:

On 25/05/2018 17:58, Rob Gaddi wrote:

So, in the spirit of explicit being better than implicit, please 
assume that for actual implementation replicate would be a static 
method of actual list, rather than the conveniently executable hackjob 
below.


_list = list
_nodefault = object()

class list(_list):
   @staticmethod
   def replicate(*n, fill=_nodefault, call=list):


That seems to work, but the dimensions are created in reverse order to 
what I expected. Which is to have the order of indices corresponding to 
the order of dimensions. So:


  x=list.replicate(2,3,4)

  print (len(x))
  print (len(x[0]))
  print (len(x[0][0]))

Gives output of 4, 3, 2 rather than 2, 3, 4.

Which means that x[0][0][3] is a bounds error.



A fair point.  Something about multidimensional arrays always makes me 
semi-dyslexic.  And there I was wondering why making it work right had 
required I rip dimensions off the list from the end instead.


Corrected version below.  list.replicate(3, 2) now means "3 of 2 of 
this" as one would expect.  This is one of those days when doctest is my 
favorite thing about Python.


_list = list
_nodefault = object()

class list(_list):
  @staticmethod
  def replicate(*n, fill=_nodefault, call=list):
"""Return a list of specified dimensions.

Fill and call can be used to prime the list with initial values, the
default is to create a list of empty lists.

Parameters:
  n : List of dimensions
  fill: If provided, the fill object is used in all locations.
  call: If fill is not provided, the result of call (a function of
  no arguments) is used in all locations.

Example:
  >>> a = list.replicate(3, 2)
  >>> a
  [[[], []], [[], []], [[], []]]
  >>> a[0][0].append('a')
  >>> a
  [[['a'], []], [[], []], [[], []]]

  >>> b = list.replicate(3, 2, fill=[])
  >>> b
  [[[], []], [[], []], [[], []]]
  >>> b[0][0].append('a')
  >>> b
  [[['a'], ['a']], [['a'], ['a']], [['a'], ['a']]]

  >>> c = list.replicate(3, 2, call=dict)
  >>> c
  [[{}, {}], [{}, {}], [{}, {}]]
  >>> c[0][0]['swallow'] = 'unladen'
  >>> c
  [[{'swallow': 'unladen'}, {}], [{}, {}], [{}, {}]]

  >>> d = list.replicate(3, 2, fill=0)
  >>> d
  [[0, 0], [0, 0], [0, 0]]
  >>> d[0][0] = 5
  >>> d
  [[5, 0], [0, 0], [0, 0]]
"""

if n:
  this = n[0]
  future = n[1:]
  return [
list.replicate(*future, fill=fill, call=call)
  for _ in range(this)
  ]
elif fill is _nodefault:
  return call()
else:
  return fill


--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.
--
https://mail.python.org/mailman/listinfo/python-list

[issue33521] Add 1.32x faster C implementation of asyncio.isfuture().

[Jimmy Lai]

Jimmy Lai  added the comment:

@vstinner
In general, we would like to make all asyncio common functions efficient with C 
implementation because CPython asyncio overhead is very expensive.
In our application, overall it costs about 10% global CPU instructions after we 
used UVLoop (it's much worse when use default event loop).
gather() is only one of the high level function bottleneck. To make CPU 
overhead not a concern for asyncio user, we should make isfuture in C because 
it's called by many other event loop functions, e.g. in asyncio/tasks.py, 
asyncio/coroutines.py, asyncio/base_events.py

--

___
Python tracker 

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

[issue1366311] SRE engine should release the GIL when/if possible

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

I'm reopening this bug even though it's been long closed and even though the 
attached patch is no longer relevant.

We recently found a degenerative performance problem with entrypoints and 
threads.  As the number of threads increases, it becomes increasingly horrible 
to extract entrypoints.  

https://github.com/takluyver/entrypoints

The problem is that entrypoints uses glob.iglob() to find the .{dist,egg}-info 
directory.  iglob() uses regexps on a fairly simple pattern.  GIL contention 
can cause entrypoint discovery with 16 threads to take ~10 seconds for all 
threads to complete.

We have some test cases that I'll try to attach later, but since my bugs 
archeology found this bug, I decided to reopen it rather than start with a new 
bug.

--
assignee: effbot -> 
components: +Extension Modules -None
keywords:  -patch
nosy: +barry
resolution: rejected -> 
status: closed -> open
title: SRE engine do not release the GIL -> SRE engine should release the GIL 
when/if possible
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

[issue18872] platform.linux_distribution() doesn't recognize Amazon Linux

[Petr Viktorin]

Petr Viktorin  added the comment:

linux_distribution is removed in Python 3.8.

--
nosy: +petr.viktorin
resolution:  -> out of date
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

[issue19213] platform.linux_distribution detects Oracle Linux as Red Hat Enterprise Linux

[Petr Viktorin]

Petr Viktorin  added the comment:

Er, sorry, I meant in 3.8.

--

___
Python tracker 

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

[issue20454] platform.linux_distribution() returns empty value on Archlinux and python 2.7

[Petr Viktorin]

Petr Viktorin  added the comment:

Er, sorry, I meant in 3.8.

--

___
Python tracker 

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

[issue19213] platform.linux_distribution detects Oracle Linux as Red Hat Enterprise Linux

[Petr Viktorin]

Petr Viktorin  added the comment:

linux_distribution is removed in Python 3.7.
Closing.

--
nosy: +petr.viktorin
resolution:  -> out of date
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

Re: List replication operator

[bartc]

On 25/05/2018 17:58, Rob Gaddi wrote:

So, in the spirit of explicit being better than implicit, please assume 
that for actual implementation replicate would be a static method of 
actual list, rather than the conveniently executable hackjob below.


_list = list
_nodefault = object()

class list(_list):
   @staticmethod
   def replicate(*n, fill=_nodefault, call=list):


That seems to work, but the dimensions are created in reverse order to 
what I expected. Which is to have the order of indices corresponding to 
the order of dimensions. So:


 x=list.replicate(2,3,4)

 print (len(x))
 print (len(x[0]))
 print (len(x[0][0]))

Gives output of 4, 3, 2 rather than 2, 3, 4.

Which means that x[0][0][3] is a bounds error.

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

[issue20454] platform.linux_distribution() returns empty value on Archlinux and python 2.7

[Petr Viktorin]

Petr Viktorin  added the comment:

linux_distribution is removed in Python 3.7.
Closing.

--
nosy: +petr.viktorin
resolution:  -> out of date
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

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

[INADA Naoki]

INADA Naoki  added the comment:

> 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.

Please note that it can't be reverted simply.
The change was introduced to ease AST-layer optimization (`"abc" + "def"` is 
not docstring, but `"abcdef"` is docstring.)
And we implemented some AST-layer optimization already.

There are two ways to revert the change:

B1. Just remove `.docstring` attribute and implement hack to distinguish string 
and docstring in some places.

B2. Remove `.docstring` attribute, but introduce `DocString` statement.  This 
was my patch (PR-5927)

In case of B2, thirdparty libraries should follow the change anyway.
In case of IPython, `DocString(s="spam")` may be replaced with 
`Expr(Str(s="spam"))`

In case of B1, I hadn't tried it yet and I don't know how difficult it is.  
I'll try but I can't say estimated time for now.

--

___
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

[Rob Gaddi]

On 05/25/2018 04:53 AM, Steven D'Aprano wrote:

On Fri, 25 May 2018 09:28:01 +0200, Peter Otten wrote:


Yet another arcanum to learn for beginners with little return. If you
cannot refrain from tinkering with the language at least concentrate on
the features with broad application. Thank you.


Broader than multi-dimensional arrays? There are a bazillion uses for
them. How many do you need before it is "broad application"?


> [snip]


This is a frequent, recurring pain point. Experienced programmers forget
how confusing the behaviour of * is because they're so used to the
execution model. They forget that writing a list comp is not even close
to obvious, not only for beginners but even some experienced Python
programmers.



I agree that it's non-obvious, but I disagree with your diagnosis.  The 
non-obvious bit is that the empty list is a reference to a newly created 
mutable, not an immutable constant.  Or, more the point, that the word 
"mutable" is one that you need to know and think about in the first place.


The thing tripping the young pups is not understanding the underlying 
Python concepts of objects and their references.  And I sympathize; 
Python's handling there is seriously non-trival.  I guarantee everyone 
on this list got bit by it when they were starting out, either in this 
case or as a default argument.  I probably still manage to screw it up a 
couple times a year due to not thinking about it clearly enough.


So, in the spirit of explicit being better than implicit, please assume 
that for actual implementation replicate would be a static method of 
actual list, rather than the conveniently executable hackjob below.


_list = list
_nodefault = object()

class list(_list):
  @staticmethod
  def replicate(*n, fill=_nodefault, call=list):
"""Return a list of specified dimensions.

Fill and call can be used to prime the list with initial values, the
default is to create a list of empty lists.

Parameters:
  n : List of dimensions
  fill: If provided, the fill object is used in all locations.
  call: If fill is not provided, the result of call (a function of
  no arguments) is used in all locations.

Example:
  >>> a = list.replicate(2, 3)
  >>> a
  [[[], []], [[], []], [[], []]]
  >>> a[0][0].append('a')
  >>> a
  [[['a'], []], [[], []], [[], []]]

  >>> b = list.replicate(2, 3, fill=[])
  >>> b
  [[[], []], [[], []], [[], []]]
  >>> b[0][0].append('a')
  >>> b
  [[['a'], ['a']], [['a'], ['a']], [['a'], ['a']]]

  >>> c = list.replicate(2, 3, call=dict)
  >>> c
  [[{}, {}], [{}, {}], [{}, {}]]
  >>> c[0][0]['swallow'] = 'unladen'
  >>> c
  [[{'swallow': 'unladen'}, {}], [{}, {}], [{}, {}]]

  >>> d = list.replicate(2, 3, fill=0)
  >>> d
  [[0, 0], [0, 0], [0, 0]]
  >>> d[0][0] = 5
  >>> d
  [[5, 0], [0, 0], [0, 0]]
"""

if n:
  this = n[-1]
  future = n[:-1]
  return [
list.replicate(*future, fill=fill, call=call)
  for _ in range(this)
  ]
elif fill is _nodefault:
  return call()
else:
  return fill


--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.
--
https://mail.python.org/mailman/listinfo/python-list

Re: List replication operator

[Chris Angelico]

On Sat, May 26, 2018 at 2:43 AM, bartc  wrote:
> On 25/05/2018 17:11, Alexandre Brault wrote:
>>
>>
>>
>> On 2018-05-25 11:40 AM, bartc wrote:
>>>
>>> On 25/05/2018 16:27, Chris Angelico wrote:

 You're way WAY too late to debate the matrix multiplication operator.
>>>
>>>
>>> /The/ matrix multiplication operator?
>>>
>>> In which language? And what was wrong with "*"?
>>>
>> In Python, the language we're discussing right now. What was wrong with
>> * is described in detail in PEP 465
>>
>>> (I've implemented matrix multiply in a language (although for
>>> specialised matrix types), and I used the same "*" symbol as was used
>>> to multiply anything else.)
>>>
>>> Anyway this is not matrix multiplication, but replication, and using
>>> '@' seems more a consequence of there not being any better ones
>>> available as they are already used for other things.
>>>
>> You're right, it's not matrix multiplication. And Pathlib's use of / is
>> not division, nor do C++'s streams use bitshifting.
>
>
> There's no need to be sarcastic.
>
> The context here for those symbols is programming source code for which
> binary or infix +, -, * and / symbols are VERY commonly used for add,
> subtract, multiply and divide operations.
>
> While some of them can sometimes be interpreted as various kinds of markup
> control when programming code is not distinguished from normal text, it can
> be particularly striking with @.

Why? Why is at-sign somehow more markuppy than asterisk, which is
*frequently* used to indicate emphasis? In fact, I have frequently run
into this, when sharing code snippets in chat systems that allow
Markdown or similar. Or if you're worried about linkification, the
humble period is far more significant. Your mail/news client might
choose to represent configure.ac as a link, since ".ac" is a valid
TLD. And datetime.date is technically valid as a domain name, though
I'm not sure if there's any actual dating site that shares a name with
this Python class.

Typable symbols are in short supply; they have different meanings in
different contexts.

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

Re: List replication operator

[Steven D'Aprano]

On Fri, 25 May 2018 17:12:12 +0100, bartc wrote:

> On 25/05/2018 16:40, Steven D'Aprano wrote:
[...]
>> On the other hand, it is arguable that what we really need is a
>> standard function to return an N-dimensional array/list:
>> 
>> # return a 3x4x5x6 4-D list initialised to all zeroes arr =
>> list.dimensions(3, 4, 5, 6, initial=0.0)
>
> What stops you just writing such a function?

Who says I haven't already?

Whether I have or not is not relevant to the question I'm asking.

Not every one-line function needs to be a built-in, but this is NOT a one-
line function, it isn't obviously easy to implement the right way (I 
started off thinking that shallow copies was the right solution, but then 
changed my mind), it is a repeated pain point in the language and a 
frequent gotcha.



-- 
Steve

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

Re: List replication operator

[bartc]

On 25/05/2018 17:11, Alexandre Brault wrote:



On 2018-05-25 11:40 AM, bartc wrote:

On 25/05/2018 16:27, Chris Angelico wrote:

You're way WAY too late to debate the matrix multiplication operator.


/The/ matrix multiplication operator?

In which language? And what was wrong with "*"?


In Python, the language we're discussing right now. What was wrong with
* is described in detail in PEP 465


(I've implemented matrix multiply in a language (although for
specialised matrix types), and I used the same "*" symbol as was used
to multiply anything else.)

Anyway this is not matrix multiplication, but replication, and using
'@' seems more a consequence of there not being any better ones
available as they are already used for other things.


You're right, it's not matrix multiplication. And Pathlib's use of / is
not division, nor do C++'s streams use bitshifting.


There's no need to be sarcastic.

The context here for those symbols is programming source code for which 
binary or infix +, -, * and / symbols are VERY commonly used for add, 
subtract, multiply and divide operations.


While some of them can sometimes be interpreted as various kinds of 
markup control when programming code is not distinguished from normal 
text, it can be particularly striking with @.



But overloading the matmul operator would allow this feature to work
without changing the syntax of the language, nor breaking existing code
(since no built-in types implement __matmul__).


As I mentioned before, why does it need to be an operator?
--
https://mail.python.org/mailman/listinfo/python-list

Re: List replication operator

[Steven D'Aprano]

On Fri, 25 May 2018 11:59:38 -0400, Dennis Lee Bieber wrote:

>   What is your definition of a multi-dimensional array -- I tend to 
think
> of them as pre-declared sizes; not the variable (row|column) lengths
> possible when using nested lists.


Any fixed size array can be implemented using a variable-sized array and 
simply NOT increasing or shrinking the array.


Don't want to append an item to the end? Then don't append an item to the 
end :-)

(If you really care, you can subclass list and override the methods which 
modify the size of the list.)


-- 
Steve

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

Re: "Data blocks" syntax specification draft

[Steven D'Aprano]

On Tue, 22 May 2018 08:01:05 +0200, Christian Gollwitzer wrote:

>>> If a block of static data is large enough to start to be ugly, a
>>> common approach is to load the data from some other file, in a
>>> language which is designed around structured data.
[...]

> Thing is, you can do it already now in the script, without modifying the
> Python interpreter, by parsing a triple-quoted string. See the examples
> right here: http://pyyaml.org/wiki/PyYAMLDocumentation


Indeed. But that requires the data be parsed at runtime, and requires 
either that you use only literals, or that you use some form of string 
interpolation.

Imagine if the only way to write a list in Python was:

make_list("[1, 2, 3, %d, 5]" % n)

instead of [1, 2, 3, n, 5]. That would be annoying and inefficient. 
Parsing triple-quoted strings is a second-class solution. While I don't 
think much of Mikhail's proposed solution (except as a good example of 
how *not* to design programming syntax) the motivation is interesting: 
can we come up with a good syntax for table-based data?

Many years ago, people got frustrated with having to define dicts like 
this:

d = {'key': value, 'a': 1, 'b': 2, ...}

and now the dict constructor allows keywords:

d = dict(key=value, a=1, b=2, ...)

which covers the very common case of keys being strings and values being 
either identifiers or numeric literals, but cases where keys and values 
are both strings, and unlike dict displays {...} the compiler can't build 
the dict at compile-time. No compile-time optimization for us!

And I know I spend a lot of unproductive time editing tables of string 
constants, making sure all the strings are quoted, etc. I would hope 
there is a better way.

There are a very small number of languages with first-class literal 
syntax for (e.g.) XML:

Kawa
https://www.gnu.org/software/kawa/XML-literals.html

Racket
http://docs.racket-lang.org/xml/

VB.Net 
https://docs.microsoft.com/en-us/dotnet/visual-basic/programming-guide/
language-features/xml/xml-literals-overview

and possibly a few others. But it seems to be a niche feature.

There's also table-driven programming:

http://wiki.c2.com/?TableOrientedProgramming

an old, proven, but undervalued technique. Probably undervalued because 
it is *too simple for non-programmers to understand*.

https://blogs.msdn.microsoft.com/ericlippert/2004/02/24/table-driven-
programming/

I can't find any languages which have native data types for building 
tables. Have I missed any? Given how ubiquitous and useful tables of 
strings or numbers are, why aren't there simple ways to build such tables 
without parsing a string at runtime?

So there's a great big hole in programming languages here.



-- 
Steve

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

Re: List replication operator

[Alexandre Brault]

On 2018-05-25 11:40 AM, bartc wrote:
> On 25/05/2018 16:27, Chris Angelico wrote:
>> You're way WAY too late to debate the matrix multiplication operator.
>
> /The/ matrix multiplication operator?
>
> In which language? And what was wrong with "*"?
>
In Python, the language we're discussing right now. What was wrong with
* is described in detail in PEP 465

> (I've implemented matrix multiply in a language (although for
> specialised matrix types), and I used the same "*" symbol as was used
> to multiply anything else.)
>
> Anyway this is not matrix multiplication, but replication, and using
> '@' seems more a consequence of there not being any better ones
> available as they are already used for other things.
>
You're right, it's not matrix multiplication. And Pathlib's use of / is
not division, nor do C++'s streams use bitshifting.
But overloading the matmul operator would allow this feature to work
without changing the syntax of the language, nor breaking existing code
(since no built-in types implement __matmul__).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: List replication operator

[bartc]

On 25/05/2018 16:40, Steven D'Aprano wrote:

On Fri, 25 May 2018 22:46:37 +1000, Chris Angelico wrote:


We've already had a suggestion for [[]]@5 and that should deal with that
issue. Steven is proposing "multiply by copying" as an alternative to
"multiply by referencing", so an alternative multiplication operator
should fit that correctly. Steve, I don't want to speak for you; can you
confirm or deny acceptance of the matmul operator as a better spelling?


I thought that ** would be less controversial than @ since that's much
newer. Silly me.

Personally, I don't care much either way. Probably a microscopic
preference for @ over ** since it is shorter, but not enough to matter.

The usefulness of * with lists is seriously compromised by the inability
to copy mutable items in the list. Consequently, it is an on-going gotcha
and pain point.

On the other hand, it is arguable that what we really need is a standard
function to return an N-dimensional array/list:

# return a 3x4x5x6 4-D list initialised to all zeroes
arr = list.dimensions(3, 4, 5, 6, initial=0.0)

What stops you just writing such a function?

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

[issue33647] Make string.replace accept a dict instead of two arguments

[R. David Murray]

Change by R. David Murray :


--
versions:  -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

[issue33647] Make string.replace accept a dict instead of two arguments

[R. David Murray]

R. David Murray  added the comment:

That is not kwargs, that's a passing a dict.  Which is what you would want, 
since the strings you want to replace might not be valid identifiers, and so 
couldn't be passed as keyword arguments.

I think I'm -0.5 on this.  I don't think complicating the api is worth the 
benefit, given that you can already chain replace calls.  (And note that before 
dicts became ordered by language definition this would have been a non-starter, 
which is probably also a mark against it.)

--
nosy: +r.david.murray
title: Make string.replace accept **kwargs instead of two arguments -> Make 
string.replace accept a dict instead of two arguments

___
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

[Chris Angelico]

On Sat, May 26, 2018 at 1:40 AM, bartc  wrote:
> On 25/05/2018 16:27, Chris Angelico wrote:
>>
>> On Fri, May 25, 2018 at 10:58 PM, bartc  wrote:
>>>
>>> I'm in general not in favour of piling in special symbols into a language
>>> just to solve some obscure or rare problem.
>>>
>>> As I went on to demonstrate, function-like syntax (or even actual
>>> functions)
>>> could do that job better, by describing what the operation does and not
>>> leaving people scratching their heads so much when they encounter that
>>> funny-looking operator hidden in 20,000 lines of code.
>>>
>>> As for '@', if a variable name can come before it /and/ after it, and
>>> either
>>> or both can be dotted, wouldn't that cause it to be highlighted as an
>>> email
>>> address in many circumstances? Such as in code posted here.
>>>
>>> (OK, let's try it and see what happens. My Thunderbird doesn't do
>>> previews
>>> so I will have to post it first:
>>>
>>> abc@def
>>> a...@def.ghi)
>>>
>>> I would find that rather annoying.
>>>
>>
>> You're way WAY too late to debate the matrix multiplication operator.
>
>
> /The/ matrix multiplication operator?

No, just *A* matrix multiplication operator, we come in sixpacks.

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

Re: List replication operator

[Chris Angelico]

On Sat, May 26, 2018 at 1:46 AM, Steven D'Aprano
 wrote:
> On Fri, 25 May 2018 18:06:00 +1000, Chris Angelico wrote:
>
>> Downside: while it's all very well to say that this is equivalent to
>> copy.deepcopy(), that would imply replicating copy.deepcopy's semantics
>> in the core list type (unless it's actually literally defined as
>> importing a module and calling a function), and deepcopy is a
>> complicated function.
>
> Betcha it's not as complicated as the import statement, and the bulk of
> that is now implemented as pure Python :-)
>
> But you make a good point: deep copying is not a trivial operation.
>

Heh, true. But "a good bit" is not quite the same as if you had (don't
shoot me, this is just hypothetical) "spam".import() as a way to
obtain the same module you'd get from 'import spam'. To be a
method/operator on a core data type, it basically *all* has to be
implemented in C, otherwise there are going to be awkwardnesses.

I don't think that kills your idea, but it does mean it's a nontrivial
enhancement to the list type.

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

Undocumented unescape() method in HTMLParser?

[Tobiah]

I came across its usage in StackOverflow somewhere, but didn't see
it in the docs.  I'm using 2.7.

I needed it while writing a class for generating text documents out of
HTML documents for attaching to emails, which lowers spam scores.  I lifted
the basis for this from the top answer here:  https://tinyurl.com/yb92x8ra

While not complete, I thought it might be of interest.  Improvements
welcome:

#

from HTMLParser import HTMLParser


def main():

parser = TextExtractor()
html = '''
head
Hi there!
 some javascript 
 class{style}
Print this
And this


'''

print parser.strip_tags(html)


class TextExtractor(HTMLParser):

def __init__(self):
HTMLParser.__init__(self)
self.silent_tag = None
self.fed = []
self.silent_tags = ['head', 'script', 'style']

def handle_starttag(self, tag, atts):
if tag in self.silent_tags:
self.silent_tag = tag

def handle_endtag(self, tag):
if tag == self.silent_tag:
self.silent_tag = None

def handle_data(self, d):
if not self.silent_tag:
self.fed.append(d)

def handle_entityref(self, name):
self.fed.append(self.unescape("&%s;" % name))

def get_data(self):
return ''.join(self.fed)

def strip_tags(self, html):
self.feed(html)
data = self.get_data()
self.fed = []
self.reset()
return data

main()

#

Output:


"Hi there!"


Print this




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

Re: List replication operator

[Steven D'Aprano]

On Fri, 25 May 2018 18:06:00 +1000, Chris Angelico wrote:

> Downside: while it's all very well to say that this is equivalent to
> copy.deepcopy(), that would imply replicating copy.deepcopy's semantics
> in the core list type (unless it's actually literally defined as
> importing a module and calling a function), and deepcopy is a
> complicated function.

Betcha it's not as complicated as the import statement, and the bulk of 
that is now implemented as pure Python :-)

But you make a good point: deep copying is not a trivial operation.


-- 
Steve

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

Re: List replication operator

[Steven D'Aprano]

On Fri, 25 May 2018 18:06:00 +1000, Chris Angelico wrote:

> Downside: while it's all very well to say that this is equivalent to
> copy.deepcopy(), that would imply replicating copy.deepcopy's semantics
> in the core list type (unless it's actually literally defined as
> importing a module and calling a function), and deepcopy is a
> complicated function.

Betcha it's not as complicated as the import statement, and the bulk of 
that is now implemented as pure Python :-)

But you make a good point: deep copying is not a trivial operation.


-- 
Steve

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

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

[STINNER Victor]

STINNER Victor  added the comment:

"""
This particular kind of bad traverse is quite easy to write if an extension 
author doesn't read docs carefully, or has read an old version of them (before 
the fix here). And resulting errors aren't too obvious. So, there's code to 
crash early and loudly in "--with-pydebug" for simple oversight cases. See 
comment at the call site of bad_traverse_test in Objects/moduleobject.c
And since there's code, there's a test to make sure it works :)
"""

Oh ok, it makes sense. Maybe the test should test at least just before 
spec.loader.create_module(). Maybe using a print().

"Thanks! Didn't know about that one, will keep it in mind for next time!"

The problem is that by default, on Linux, we don't dump core files on the 
current directory. So such bug is silent on Linux. But it's commonly detected 
on FreeBSD since I configured the test runner to fail if it leaves a new file.

--

___
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

[Matthias Bussonnier]

Matthias Bussonnier  added the comment:

Łukasz Langa wrote:

> Inadasan, I think what we should do is to amend `ast.parse()` and `compile()` 
> docs that mode="exec" treats given code as a module, we should even give the 
> docstring handling as an example.

That is what I proposed in https://bugs.python.org/issue33477
and in PR https://github.com/python/cpython/pull/6973

The other surprise, is that even is I  knew AST were change and had a docstring 
field I was not expecting `compile()` to be affected.


I think that the change for ast to have a docstring field is a good one from an 
API point of view for ast nodes. But It should probably be opt-in, at least 
with a deprecation period to make it the default. The other issue is that as it 
affect only sequence of statement where the first node is (was) a string, it 
can lead to really subtle difference in execution. 



MinRk said:
> The only affected case for us is interactively typed string literals in 
> single statement cells not displaying themselves as results

It might affect our downstream consumers that have syntax/ast transformation 
like sage, sympy on top of IPython. I doubt we have any but it's a possibility. 

While I would prefer (B) as well, I see how the new behavior can be useful in 
some case, and strongly also support the addition of a `multiline` mode, which 
correspond to what 3.6 and before were doing with `exec`. The other possibility 
is to leave `exec` and `ast.parse` with 3.6 behavior, and include a `'module'` 
mode that does reflect current 3.7 behavior.

--
nosy: +mbussonn

___
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

[bartc]

On 25/05/2018 16:27, Chris Angelico wrote:

On Fri, May 25, 2018 at 10:58 PM, bartc  wrote:

I'm in general not in favour of piling in special symbols into a language
just to solve some obscure or rare problem.

As I went on to demonstrate, function-like syntax (or even actual functions)
could do that job better, by describing what the operation does and not
leaving people scratching their heads so much when they encounter that
funny-looking operator hidden in 20,000 lines of code.

As for '@', if a variable name can come before it /and/ after it, and either
or both can be dotted, wouldn't that cause it to be highlighted as an email
address in many circumstances? Such as in code posted here.

(OK, let's try it and see what happens. My Thunderbird doesn't do previews
so I will have to post it first:

abc@def
a...@def.ghi)

I would find that rather annoying.



You're way WAY too late to debate the matrix multiplication operator.


/The/ matrix multiplication operator?

In which language? And what was wrong with "*"?

(I've implemented matrix multiply in a language (although for 
specialised matrix types), and I used the same "*" symbol as was used to 
multiply anything else.)


Anyway this is not matrix multiplication, but replication, and using '@' 
seems more a consequence of there not being any better ones available as 
they are already used for other things.


--
bartc

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

Re: List replication operator

[Steven D'Aprano]

On Fri, 25 May 2018 22:46:37 +1000, Chris Angelico wrote:

> We've already had a suggestion for [[]]@5 and that should deal with that
> issue. Steven is proposing "multiply by copying" as an alternative to
> "multiply by referencing", so an alternative multiplication operator
> should fit that correctly. Steve, I don't want to speak for you; can you
> confirm or deny acceptance of the matmul operator as a better spelling?

I thought that ** would be less controversial than @ since that's much 
newer. Silly me.

Personally, I don't care much either way. Probably a microscopic 
preference for @ over ** since it is shorter, but not enough to matter.

The usefulness of * with lists is seriously compromised by the inability 
to copy mutable items in the list. Consequently, it is an on-going gotcha 
and pain point.

On the other hand, it is arguable that what we really need is a standard 
function to return an N-dimensional array/list:

# return a 3x4x5x6 4-D list initialised to all zeroes
arr = list.dimensions(3, 4, 5, 6, initial=0.0)




-- 
Steve

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

[issue33648] unused with_c_locale_warning option in configure should be removed

[Eitan Adler]

Eitan Adler  added the comment:

yeah, I was looking at that too. I think someone else modified related files 
but never ran a regen (or did so with different tooling than I).

Even on master, my regen results in changes.

--

___
Python tracker 

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

[issue33645] Importing bs4 fails with -3 option in Python 2.7.15

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

___
Python tracker 

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

[issue33645] Importing bs4 fails with -3 option in Python 2.7.15

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Ah, I was fooled by the message about Beautiful Soup. It is not a message of an 
error, it is a part of source line, printed for a SyntaxError. Seems sources of 
Beautiful Soup intentionally contain a code invalid in Python 3.

There is a bug in Python. The tokenizer returns error E_OK, but it should never 
return such error code. The AST parser is confused and raises a SyntaxError 
with the message "unknown parsing error".

This bug is reproduced when run Python wish both options -3 and -We and parse 
the "<>" operator.

$ ./python -3 -We -c '[] <> []'
error=10
  File "", line 1
[] <> []
^
SyntaxError: unknown parsing error

But it is reproduced with 2.7.14 too.

--
resolution: third party -> 
stage: resolved -> 
status: closed -> open

___
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

[Steven D'Aprano]

On Fri, 25 May 2018 13:58:03 +0100, bartc wrote:

> As for '@', if a variable name can come before it /and/ after it, and
> either or both can be dotted, wouldn't that cause it to be highlighted
> as an email address in many circumstances? Such as in code posted here.

Sure.

And x/y might be formatted as a file system pathname in many 
circumstances, and x

Re: List replication operator

[Chris Angelico]

On Fri, May 25, 2018 at 10:58 PM, bartc  wrote:
> I'm in general not in favour of piling in special symbols into a language
> just to solve some obscure or rare problem.
>
> As I went on to demonstrate, function-like syntax (or even actual functions)
> could do that job better, by describing what the operation does and not
> leaving people scratching their heads so much when they encounter that
> funny-looking operator hidden in 20,000 lines of code.
>
> As for '@', if a variable name can come before it /and/ after it, and either
> or both can be dotted, wouldn't that cause it to be highlighted as an email
> address in many circumstances? Such as in code posted here.
>
> (OK, let's try it and see what happens. My Thunderbird doesn't do previews
> so I will have to post it first:
>
>abc@def
>a...@def.ghi)
>
> I would find that rather annoying.
>

You're way WAY too late to debate the matrix multiplication operator.

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

[issue33648] unused with_c_locale_warning option in configure should be removed

[Nick Coghlan]

Nick Coghlan  added the comment:

Huh, I thought I cleaned those out when I made the compilation unconditional. I 
guess not :)

The actual fix looks good to me, but the autoconf regeneration looks 
unexpectedly noisy, so I've asked Benjamin Peterson to take a look at it.

--

___
Python tracker 

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

[issue26826] Expose new copy_file_range() syscall in os module.

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

Check for availability in configure.ac appears to be broken.

--

___
Python tracker 

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

[issue33645] Importing bs4 fails with -3 option in Python 2.7.15

[Florian Schulze]

Florian Schulze  added the comment:

Yes, it's third party code, but that worked up until Python 2.7.14 and only 
broke with 2.7.15, which is why I reported it here.

The expected behaviour is not a SyntaxError, but a DeprecationWarning, which is 
what you get pre Python 2.7.15. So this is a regression.

--

___
Python tracker 

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

[issue33648] unused with_c_locale_warning option in configure should be removed

[Eitan Adler]

Change by Eitan Adler :


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

___
Python tracker 

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

[issue33648] unused with_c_locale_warning option in configure should be removed

[STINNER Victor]

STINNER Victor  added the comment:

It's related to the PEP 538.

Note: see also the PEP 540 (not directly related).

--
nosy: +ncoghlan, vstinner

___
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]

Change by Serhiy Storchaka :


--
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

[issue33648] unused with_c_locale_warning option in configure should be removed

[Eitan Adler]

New submission from Eitan Adler :

There is an option for --with-c-locale-warning which was turned into a run-time 
option in eb81795d7d3a8c898fa89a376d63fc3bbfb9a081. The configuration should be 
cleaned up.

--
messages: 317676
nosy: eitan.adler
priority: normal
severity: normal
status: open
title: unused with_c_locale_warning option in configure should be removed

___
Python tracker 

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