[issue33316] Windows: PyThread_release_lock always fails

[Ivan Pozdeev]

Ivan Pozdeev  added the comment:

> So, nothing more to do here.

In case that was cryptic, it means: the PR can be acted upon, no other changes 
are needed.

--

___
Python tracker 

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

[issue18307] Relative path in co_filename for zipped modules

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

In year 2018 you have to create a pull request on GitHub. See 
https://devguide.python.org/.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue33565] strange tracemalloc results

[INADA Naoki]

Change by INADA Naoki :


--
nosy: +inada.naoki

___
Python tracker 

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

[issue33583] PyObject_GC_Resize() doesn't relink GCHead

[INADA Naoki]

Change by INADA Naoki :


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

Re: "Data blocks" syntax specification draft

[Joe Pfeiffer]

Mikhail V  writes:

> On Mon, May 21, 2018 at 1:41 PM, Chris Lindsay via Python-list
>  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.
>
>
> Maybe it is common in industrial applications but not in smaller production,
> and according to my observation not common at all in all occasional scripts.

It is absolutely standard in all applications that have a configuration
file.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Mikhail V]

On Mon, May 21, 2018 at 3:48 PM, bartc  wrote:

>
> This is intended to be used inside actual Python programs?
>
> In that case code is normally displayed in fixed pitch, as it would normally
> be viewed in a code editor, even if part of a document.
>
> But I have to say it looks pretty terrible, and I can't see that it buys
> much over normal syntax.

Ha, here we go. Last time I have used fixed pitch font for work -
maybe 4 years ago.
(and IMO fixed pitch font plus specifically Python - I find quite a blasphemy)

So, you re right, of course in one sense: "///" looks terrible with
a fixed pitch font! That's so true, but also it is true that this ///
I well maybe change for something less font-sensitive.
And in all fonts other than fixed pitch it looks cute enough.

Simply speaking, if it was not for Python, I might propose something
like:

# t
   # t
  11  22  33

You get the point?
So basically all nice chars are already occupied.
Proposing Unicode symbols -- that will probably will be
dead on arrival (just remembering some of such past proposals).
Leaving out symbols could be an option as well.
Still the structure needs a syntactical entry point.
E.g.

data = ///
t
   t
  11  22  33

Hmm. not bad. But I must think about parsing as well.


> It's not clear what ///. is for, or why it's necessary (presumably you have
> to use ///. /// instead of /// ///).

"///."  is meant to inherit the previous (parent) type:

/// t
   /// .
  /// .

is same as

/// t
   /// t
  /// t

So I can change types of all child nodes with one keystroke.


>
> The ///d dictionary example is ambiguous: can you have more than one
> key:value per line or not? If so, it would look like this:
>
>   ///d "a" "b" "c" "d" "e" "f"

///d   "a" "b""c" "d""e" "f"

Now better? :-)

Or compare these two:

{"a": "b", "c": "d", "e": "f"}

///d   "a" "b""c" "d""e" "f"

I'd say, the second one is much better.


> Or do you also allow: date = ///  with data following on the next line?

Yes, all this should be legal:

data = /// t
   11 22 33

data =\
/// t
   11 22 33

data = /// t  11 22 33


But this probly not good:

data = /// t  11 22 33  /// t  44  55

Because it will not be clear for the reader how further suite termination
happens.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Ben Finney]

Ned Batchelder  writes:

> You've proposed it and asked for feedback, but you seem to be
> completely ignoring the feedback people are giving you.

Another problem with the proposal: The motivation to introduce such a
large change is not compelling. What is the problem this proposal aims
to solve? Why solve it with such a large amount of fundamental change,
when (as discussed in this thread) there are apparently many existing
solutions that work well?

If there's a problem that existing solutions are not addressing well,
the proposal needs to do the work of explicitly stating the problem and
its constraints, demonstrating an understanding of those existing
solutions and how they are inadequate to the explicitly described
problem.

-- 
 \ “If you can do no good, at least do no harm.” —_Slapstick_, |
  `\ Kurt Vonnegut |
_o__)  |
Ben Finney

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

Re: "Data blocks" syntax specification draft

[Ned Batchelder]

On 5/21/18 9:42 PM, Mikhail V wrote:

On Mon, May 21, 2018 at 2:14 PM, Ned Batchelder  wrote:

On 5/19/18 10:58 PM, Mikhail V wrote:

I have made up a printable PDF with the current version
of the syntax suggestion.

https://github.com/Mikhail22/Documents/blob/master/data-blocks-v01.pdf

After some of your comments I've made some further
re-considerations, e.g. element separation should
be now much simpler.
A lot of examples with comparison included.


Comments, suggestions are welcome.


Mikhail, you have a completely different esthetic for syntax than the rest
of the Python world.

In what sense? I don't propose to add braces to Python or anything like that.



In the sense that no one likes it.  I don't mean to be blunt, but it 
doesn't look or act like Python, and it replaces existing structures 
with things that are completely different.


You've proposed it and asked for feedback, but you seem to be completely 
ignoring the feedback people are giving you.


It's not going to be added to Python. Write it as a third-party library.

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

[issue33583] PyObject_GC_Resize() doesn't relink GCHead

[miss-islington]

miss-islington  added the comment:


New changeset 0c1e7d8122808d42f9fdb7019061dc2e78a78efa by Miss Islington (bot) 
in branch '3.6':
bpo-33583: Add note in PyObject_GC_Resize() doc (GH-7021)
https://github.com/python/cpython/commit/0c1e7d8122808d42f9fdb7019061dc2e78a78efa


--

___
Python tracker 

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

Re: "Data blocks" syntax specification draft

[Mikhail V]

On Mon, May 21, 2018 at 1:41 PM, Chris Lindsay via Python-list
 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.


Maybe it is common in industrial applications but not in smaller production,
and according to my observation not common at all in all occasional scripts.

>YAML comes to mind

Actually plugging a data syntax in existing language is not a new idea.
Though I don't know real success stories.

> What use-case do you foresee for your proposed new format, that isn't
> already (better) accomplished by using a separate structured
> data/serialisation language?

Well everything described in the doc is quite common. So simply put,
for all data beyond trivial inline [1,2,3].

If your idea is to use external data for all scenarios - then there are
many questions - which toolchains, file organisation, distribution etc.
One common approach is an TSV/ CSV editor plus a quick dirty
self-defined parser.
One criteria for a syntax - how simple to edit it in normal text editor
and how other existing data editors can do it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Mikhail V]

On Mon, May 21, 2018 at 2:14 PM, Ned Batchelder  wrote:
> On 5/19/18 10:58 PM, Mikhail V wrote:
>>
>> I have made up a printable PDF with the current version
>> of the syntax suggestion.
>>
>> https://github.com/Mikhail22/Documents/blob/master/data-blocks-v01.pdf
>>
>> After some of your comments I've made some further
>> re-considerations, e.g. element separation should
>> be now much simpler.
>> A lot of examples with comparison included.
>>
>>
>> Comments, suggestions are welcome.
>>
>
> Mikhail, you have a completely different esthetic for syntax than the rest
> of the Python world.

In what sense? I don't propose to add braces to Python or anything like that.

> Your proposal seems to have almost nothing in common
> with existing Python syntax.

Well, if  speak of adding any embedded data syntax at all - how do you think:
should the embedded syntax copy everything? Even if it will look worse
in the end?
Frankly, I don't think so.
If you ask me:  may it be totally different syntax than Python?
I'd say - no, but it should be something compromising.

What other criteria is there?
Main benefits i see in Python syntax: indentation-based,
no termination tokens, new-line statement separation. Overall tendency
to prioritize readability
(e.g. over parse-ability). All these points i try to oblige.
Actually if think deeper of it - these points are not even something "Pythonic"
but merely just common sense and some basic readability principles.

> Your approach to whitespace is different.
> You've ignored existing words (tuple, str) in favor of new shorthands (t,s).

Yes. Turns out these two things should work better for presentation,
so nothing much unexpectable and nothing personal against existing words ;-).
Type abbreviations deserve more explanation in the doc though.
Simply put - if I write whole words - then type names _will dominate over data_.
E.g.:

/// tuple
   /// tuple
  foo  bar

and even so:

tuple:
   tuple:
  foo  bar

Might it be that the latter is more 'Pythonic'? Maybe yes. But how it
will look on average structure - should be compared.
Again: with proper highlighting this _might_ be an option, but without
highlighting -
sorry, would be just too hard to eyeball the nodes.

Regarding further smaller details - semicolons, asterisks - those are
subject for
further observations and may change.


> Parentheses enclosing strings!?

:-) Ok, here I agree -   the whole 'string type' part - that would be
just too much to
slip through. This would cause inconsistence and add confusion when
placed together with
normal token presentation structs. Although e.g. in a separate file
with a string-only data
it could make the difference.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue33470] Changes from GH-1638 (GH-3575, bpo-28411) are not documented in Porting to Python 3.7

[Eric Snow]

Eric Snow  added the comment:

Under Py_LIMITED_API:

typedef struct _is PyInterpreterState;

Also, the actual removal of the "modules" field was reverted.  The field is 
still there until I get back to fixing 
https://github.com/python/cpython/pull/3606.

--

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

[Andrés Delfino]

Change by Andrés Delfino :


--
keywords: +patch
pull_requests: +6681
stage:  -> 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"

[Andrés Delfino]

New submission from Andrés Delfino :

There a couple of references to lambda parameters mentioned as arguments. I'm 
proposing fixing them.

--
assignee: docs@python
components: Documentation
messages: 317255
nosy: adelfino, docs@python
priority: normal
severity: normal
status: open
title: FIx references to lambda "arguments"
type: enhancement
versions: Python 2.7, 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

[issue32092] mock.patch with autospec does not consume self / cls argument

[Cheryl Sabella]

Change by Cheryl Sabella :


--
nosy: +michael.foord
versions:  -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

[issue33523] loop.run_until_complete re-entrancy to support more complicated codebases in transition to asyncio

[Jason Fried]

Jason Fried  added the comment:

For loops not supporting this throwing NotImplmentedError from the method to 
enable reentrancy seems appropriate. 

"You should convert all your stack to async functions..."

That may not be practical for large code bases in transition to asyncio. The 
fixes for reentrancy that I find in reality are not adding async logic through 
out the call stack but instead its one of the two I listed.

--

___
Python tracker 

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

[issue18307] Relative path in co_filename for zipped modules

[Vitaly Murashev]

Vitaly Murashev  added the comment:

Guys, a couple questions ...
I want to suggest new patches for python3.7 and python2.7 with regression tests 
included
What is proper way to do it now, in year 2018 ?
May I do it on github.com ? Should I submit new issue for that there ?
Or am I still supposed to attach new patches here - on bugs.python.org ?

--

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

[Matthias Bussonnier]

Change by Matthias Bussonnier :


--
keywords: +patch
pull_requests: +6680
stage:  -> 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.

[Matthias Bussonnier]

New submission from Matthias Bussonnier :

inspect's getargspec, as well as Signature's from_function, and from_builtin 
are deprecated. 

They all emits DeprecationWarning but: 

The deprecation warning does not say since which version since are deprecated. 
For the two Signature's methods, there is no documentation available, so 
finding this information is difficult. 

Many tool rely on introspection to provide object help via docstring, which 
also did not include this deprecation notice. 

Adding the deprecation informations to these 3 function/methods would be good 
to foster migration to newer ways.

--
assignee: docs@python
components: Documentation
messages: 317252
nosy: docs@python, mbussonn
priority: normal
severity: normal
status: open
title: add deprecation since 3.5 for a few methods of inspect.
versions: Python 3.5, 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

[issue33361] readline() + seek() on codecs.EncodedFile breaks next readline()

[Josh Rosenberg]

Change by Josh Rosenberg :


--
title: readline() + seek() on io.EncodedFile breaks next readline() -> 
readline() + seek() on codecs.EncodedFile breaks next readline()

___
Python tracker 

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

[issue33590] sched.enter priority has no impact on execution

[R. David Murray]

R. David Murray  added the comment:

I think Ronald is correct.

The priority argument for enter would apply if you called enter twice with two 
different delays, but they happen to end up pointing to the same moment in time 
from the scheduler's point of view.

How would the computer know that two calls to enter with the same delay are 
supposed to point to the same moment in time?

But you are correct, it looks like the example would make more sense if it used 
enterabs, not enter.

You can test our theory by writing time and delay functions with a course 
enough resolution that two sequential calls to delay will end up pointing to 
the time time unit.  (Or we could look at the code :)

--
nosy: +r.david.murray

___
Python tracker 

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

[issue33593] Support heapq on typed arrays?

[Diego Argueta]

New submission from Diego Argueta :

It'd be really great if we could have support for using the `heapq` module on 
typed arrays from `array`. For example:


```
import array
import heapq
import random

a = array.array('I', (random.randrange(10) for _ in range(10)))
heapq.heapify(a)
```

Right now this code throws a TypeError:

TypeError: heap argument must be a list


I suppose I could use `bisect` to insert items one by one but I imagine a 
single call to heapify() would be more efficient, especially if I'm loading the 
array from a byte string.

>From what I can tell the problem lies in the C implementation, since removing 
>the _heapq imports at the end of the heapq module (in 3.6) makes it work.

--
components: Library (Lib)
messages: 317250
nosy: da
priority: normal
severity: normal
status: open
title: Support heapq on typed arrays?
type: enhancement
versions: Python 2.7, Python 3.6

___
Python tracker 

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

Re: Python 3.6 causes error, python 3.5 does not.

[Jim]

On 05/20/2018 02:03 PM, Jim wrote:

Mint 18
Libreoffice 5.1.6.2
Python 3.6.5 in one virtual environment
Python 3.5.2 in another

I am writing a script that uses pyautogui to get some data and paste it 
into a Libreoffice calc file, there by bypassing the complexity of uno.


The problem is it runs fine if I use python 3.5. If I use python 3.6 it 
opens the calc file then pops up a dialog saying "std::bad_alloc". There 
are no relevant errors in the terminal. At this point I must reload the 
file and let calc recover it. I googled "std::bad_alloc" but didn'


This is the portion of the code that causes the error:

import pyautogui
import subprocess
import threading
import time

LONG_ENOUGH = 5

class LO():
     '''Manipulate libreoffice not using UNO'''
     def __init__(self):
     self.filename = 
'/home/jfb/Documents/Financial/Investing/Stocks.ods'
     opener = threading.Thread(target=self.open_it, 
args=(self.filename,))

     opener.start()
     time.sleep(5) #LONG_ENOUGH)
     #self.manipulate_LO()

     #Open and work with libreoffice
     def open_it(self, filename):
     #subprocess.call(["libreoffice", filename])
     subprocess.run(["libreoffice", filename])

lo = LO()

To complicate matters not all .ods files show this problem. I ran some 
tests. Two of my .ods files are effected but a couple of others are not. 
A new test file I created is not effected.


I don't know if I have a Libreoffice problem, file corruption or a 
Python problem. The fact that 3.6 gives an error but 3.5 does not is the 
reason I decided to ask here first.


Regards,  Jim



To follow up. I just discovered the error only happens if I start the 
script from inside the 3.6 virtual environment. If I start it from 
another terminal with the full path to the 3.6 VE and the script it runs 
without error.


Regards,  Jim

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

[issue33590] sched.enter priority has no impact on execution

[sahilmn]

sahilmn  added the comment:

The task schedule is executed when `s.run()` is called. There should be a
*delay = 5*  from the time the scheduling statement is executed.

If your claim is true, the priority argument is useless since it has no
impact on the execution order when `delay` values are equal. Clearly, this
is not the case since the example for `enter` at
https://docs.python.org/3/library/sched.html aims to demonstrate the use of
`priority` argument.

On Mon, May 21, 2018 at 4:14 AM, Ronald Oussoren 
wrote:

>
> Ronald Oussoren  added the comment:
>
> I don't think  there's a bug here: sched.enter schedules an event some
> time after the current time. The two calls to sched.enter are not at the
> same time, hence the priority is not used because the events are scheduled
> at different times.
>
> --
> nosy: +ronaldoussoren
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

RE: "Data blocks" syntax specification draft

[Dan Strohl via Python-list]

On 5/19/18 10:58 PM, Mikhail V wrote:
>> I have made up a printable PDF with the current version of the syntax 
>> suggestion.
>>
>> https://github.com/Mikhail22/Documents/blob/master/data-blocks-v01.pdf
>>
>> After some of your comments I've made some further re-considerations, 
>> e.g. element separation should be now much simpler.
>> A lot of examples with comparison included.
>>
>>
>> Comments, suggestions are welcome.
>>
>
>Mikhail, you have a completely different esthetic for syntax than the rest of 
>the Python world.  Your proposal seems to have almost nothing in common with 
>existing Python syntax.  Your approach to >whitespace is different. You've 
>ignored existing words (tuple, str) in favor of new shorthands (t, s).  You 
>use semicolon and asterisk for something new. Parentheses enclosing strings!?
>
>This is never going to be adopted as Python syntax. It's too different.
>
>That's fine: make a new file format.  Write a library that can read and write 
>this format.  Propose it to people, and get them using it.  We have xml, ini, 
>json, yaml, and toml.  Now we can also have data >blocks.

Mikhail,

I'm afraid I would have to agree with Ned,   in looking at it, this did not 
seem to be any less complex than existing python structures, nor was it 
significantly less typing (in many cases) after you put the /// in there.

Also there were several places where it's not deterministic enough around data 
types... how would it handle a tuple like:

test=(0x991, 0x01, 'Hello', 123e334562.9, 1, '1', "This is a single string 
(including this)",  custom_object)

I get the idea of trying to remove some of those extra punctuation marks, but 
they exist for a reason, and removing them just leads to a more complex world 
of "sometimes you use them and sometimes you don’t".

For the dictionary type, with odd elements being keys and even being values, 
that can get really hard to visually parse if you have a long block in a row... 
for example:

///d abc def ghi jkl mno pqr stu vwx yz1 ab2 cd4

Would break, but... where?  Which parts are supposed to be keys v. values?

You mentioned ease of import of data in your summary, I haven't seen any data 
files that use a format like this, so I don’t offhand see that value, but if it 
is, as Ned mentioned, then doing a translator object for it makes sense.  
Approach this like a new data format (like XML, JSON, etc) Then also, if it 
ends up taking off, you are better placed to come back and say "see, everyone's 
using this format, Python should handle it by default".

Finally, you mentioned several "main problems".  Those I totally agree with, 
but I don’t think you realize how complex they are.  The parser would have 
nightmares trying to parse some of these structures into tokens without having 
a totally different parser engine just for that, and there are lots of corner 
cases that would break this approach and would need a different approach, 
requiring a long list of caveats, and at least personally, I just don't see the 
value there.  The few places where it seems like it would be a benefit are 
pretty small, and the places where it makes things more complex seem common.

Dan Strohl


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

Re: best way to remove leading zeros from a tuple like string

[brucegoodstein]

On Monday, May 21, 2018 at 1:05:52 PM UTC-4, Rodrigo Bistolfi wrote:
> >>> repr(tuple(int(i) for i in s[1:-1].split(',')))
> '(128, 20, 8, 255, -1203, 1, 0, -123)'
> 
> 2018-05-21 4:26 GMT-03:00 Peter Otten <__pete...@web.de>:
> 
> > bruceg113...@gmail.com wrote:
> >
> > > Looking over the responses, I modified my original code as follows:
> > >
> >  s = "(128, 020, 008, 255, -1203,01,-000, -0123)"
> >  ",".join([str(int(i)) for i in s[1:-1].split(",")])
> > > '128,20,8,255,-1203,1,0,-123'
> >
> > I think this looks better with a generator instead of the listcomp:
> >
> > >>> ",".join(str(int(i)) for i in s[1:-1].split(","))
> > '128,20,8,255,-1203,1,0,-123'
> >
> >
> > --
> > https://mail.python.org/mailman/listinfo/python-list
> >


I am not familiar with the repr statement.
Looking into your response, I like it.
There is no need to add-in the parentheses.

With the repr statment:
>>> bb = repr (tuple (int (i) for i in s [1: -1] .split (',')))
>>> bb
'(128, 20, 8, 255, -1203, 1, 0, -123)'
>>> type(bb)

>>>

Without the repr statement:
>>> aa = (tuple (int (i) for i in s [1: -1] .split (',')))
>>> aa
(128, 20, 8, 255, -1203, 1, 0, -123)
>>> type(aa)

>>>

Thanks,
Bruce



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

[issue33589] Remove dummy member in GCHead

[Gregory P. Smith]

Change by Gregory P. Smith :


--
nosy: +twouters

___
Python tracker 

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

Re: "Data blocks" syntax specification draft

[Marko Rauhamaa]

Mikhail V :
> How do you do that?! You're truly unsurpassed master of polemics. How
> you turn everything upside down so easily?

If someone's behavior annoys you too much, just put them in your kill
file.

(And no, you don't have to declare it publically.)


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

Re: "Data blocks" syntax specification draft

[Chris Angelico]

On Tue, May 22, 2018 at 4:08 AM, Mikhail V  wrote:
>>> Ok. How is about images? this proposal will require a lot of images
>>> - otherwise people who read it are forced to copy-paste snippets
>>> into their code editors to understand how it may look in reality.
>>
>> If you're proposing syntax for Python, it's ultimately going to have
>> to be text.
>
> All of files that I provided are TEXT. Well maybe PDF is a bit "less text
> than TXT" but still its just text pieces.

Funny, I'm pretty sure I heard you say that your proposal would
require a lot of images. Or are images somehow just a bit less text
than text too?

I'm not interested in a proposal that is hard to read, for a syntax
that is utterly unpythonic, to achieve something that is better done
with a data file format. Bye!

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

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

[W deW]

W deW  added the comment:

Changing the documentation in tis way seems to me an excellent and easy way to 
solve the issue.

--

___
Python tracker 

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

[issue33533] Provide an async-generator version of as_completed

[Hrvoje Nikšić]

Hrvoje Nikšić  added the comment:

Another option occurred to me: as_completed could return an object that 
implements both synchronous and asynchronous iteration protocol:


class as_completed:
def __init__(fs, *, loop=None, timeout=None):
self.__fs = fs
self.__loop = loop
self.__timeout = timeout

def __iter__(self):
# current implementation here
...

async def __aiter__(self):
# new async implementation here
...

def __next__(self):
# defined for backward compatibility with code that expects
# as_completed() to return an iterator rather than an iterable
if self._iter is None:
self._iter = iter(self)
return next(self._iter)

With that design there wouldn't need to be a new function under a different 
name; instead, as_completed could just be documented as an asynchronous 
iterable, with the old synchronous iteration supported for backward 
compatibility.

--

___
Python tracker 

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

[issue25457] json dump fails for mixed-type keys when sort_keys is specified

[R. David Murray]

R. David Murray  added the comment:

json keys *are* strings, so the fact that we support other object types as keys 
and coerce them to strings is an "extra feature" of python, and is actually a 
somewhat questionable feature.  The reproducible use case is solved by the fact 
that dicts are now ordered, with no extra work on the part of the programmer.  
Likewise, if you want custom sorting you can ensure your dict is ordered the 
way you want it to be, as you indicate.  The remaining use case for sort_keys, 
then (and one for which it is *commonly* used) is sorting the keys 
lexicographically, and for that, sorting the coereced strings is correct per 
the json standard (in which all keys are required to be strings).

Note that sort_keys will not be removed for backward compatibility reasons, so 
the only question is whether or not the increased functionality of coercing 
first is worth the trouble to implement.  I'm actually only +0 on it, since I 
don't consider it good practice to json-ize dicts that have non-string keys.  
The reason I'm + is because it would increase backward compatibility with 
python2 (not the ordering of the output, we can't make that work, but in the 
fact that it would no longer raise an error in python3).

We'll see if other core developers agree or disagree.

--

___
Python tracker 

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

Re: "Data blocks" syntax specification draft

[Mikhail V]

On Mon, May 21, 2018 at 7:05 AM, Chris Angelico  wrote:
>>> Forcing us to download a PDF and then read it? Well, it's your
>>> decision. My decision is that I cannot be bothered going to THAT much
>>> effort to figure out what you're saying.
>>
>> THAT much effort to click two times instead of one - and get a
>> formatted document instead of plain bw text. o-kaay..
>
> Two clicks? No, that isn't how it happened for me. I clicked on it and
> then I couldn't see the content.

Sorry I don't know - seems that everyone can see it.

> What second click am I supposed to do
> that shows me the page?

No, no second click is needed. But if you want to download a file -
there is a button "download file". So in a pair of clicks you get
a file on your PC and you can use your favorite viewer to view
PDF, which is IMO more convenient than in a browser.

>> Ok. How is about images? this proposal will require a lot of images
>> - otherwise people who read it are forced to copy-paste snippets
>> into their code editors to understand how it may look in reality.
>
> If you're proposing syntax for Python, it's ultimately going to have
> to be text.

All of files that I provided are TEXT. Well maybe PDF is a bit "less text
than TXT" but still its just text pieces.

> You cannot say "and every text editor has to render it
> like this". If you can't demonstrate it using plain text, you have a
> major problem on your hands.

How do you do that?!  You're truly unsurpassed master of polemics.
How you turn everything upside down so easily? - that is _me_ who tells
to make _various_ samples so as to be able to see difference by
various fonts. And it is _you_ who say "everybody look at black and
white sample with a font out of 80' ".
WTF means "If you can't demonstrate it using plain text"?
There is nothing more simple than demonstrate it in plain text.
But it is not enough to judge the syntax since there is
_huge_ difference of fonts, and presence of highlighting makes huge
difference especially for expressions with keywords.

>>> I'm not going to read your proposal if you force me to go to heaps of
>>> effort for it.
>>
>> heaps! oh come on, youre making up again.
>
> No, I'm not making it up. Just because the PDF works perfectly for
> you, you assume that it'll work perfectly for everyone.

Look, PDF is one of the most widely used document exchange formats.
And you know it. I personally  don't need the PDF either - creating it
just adds me
work. And I am not debating anything about it, just made it for convenience
since someone maybe prefer it.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue33361] readline() + seek() on io.EncodedFile breaks next readline()

[Diego Argueta]

Diego Argueta  added the comment:

Update: Tested this on Python 3.5.4, 3.4.8, and 3.7.0b3 on OSX 10.13.4. They 
also exhibit the bug. Updating the ticket accordingly.

--
versions: +Python 3.4, Python 3.5, Python 3.7

___
Python tracker 

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

[issue33592] Document contextvars C API

[Elvis Pranskevichus]

Change by Elvis Pranskevichus :


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

___
Python tracker 

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

[issue33592] Document contextvars C API

[Elvis Pranskevichus]

New submission from Elvis Pranskevichus :

The C API for PEP 567 is currently missing.

--
assignee: docs@python
components: Documentation
messages: 317244
nosy: Elvis.Pranskevichus, docs@python, yselivanov
priority: normal
severity: normal
status: open
title: Document contextvars C API
type: enhancement
versions: Python 3.7

___
Python tracker 

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

[issue25457] json dump fails for mixed-type keys when sort_keys is specified

[Aaron Hall]

Aaron Hall  added the comment:

>From a design standpoint, I'm fairly certain the sort_keys argument was 
>created due to Python's dicts being arbitrarily ordered.

Coercing to strings before sorting is unsatisfactory because, e.g. numbers sort 
lexicographically instead of by numeric value when strings.

>>> import json
>>> json.dumps({i:i**2 for i in range(15)}, sort_keys=True)
'{"0": 0, "1": 1, "2": 4, "3": 9, "4": 16, "5": 25, "6": 36, "7": 49, "8": 64, 
"9": 81, "10": 100, "11": 121, "12": 144, "13": 169, "14": 196}'
>>> json.dumps({str(i):i**2 for i in range(15)}, sort_keys=True)
'{"0": 0, "1": 1, "10": 100, "11": 121, "12": 144, "13": 169, "14": 196, "2": 
4, "3": 9, "4": 16, "5": 25, "6": 36, "7": 49, "8": 64, "9": 81}'

Changing the order of operations is just going to create more issues, IMHO.

Now that users can sort their dicts prior to providing them to the function, 
e.g.:

>>> json.dumps({str(i):i**2 for i in range(15)})
'{"0": 0, "1": 1, "2": 4, "3": 9, "4": 16, "5": 25, "6": 36, "7": 49, "8": 64, 
"9": 81, "10": 100, "11": 121, "12": 144, "13": 169, "14": 196}'

we could deprecate the argument, or just keep it as-is for hysterical raisins.

Regardless, I'd close this as "won't fix".

--

___
Python tracker 

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

[issue33531] test_asyncio: test_subprocess test_stdin_broken_pipe() failure on Travis CI

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Fixed failed sendfile tests on Windows (at least I hope so).

--

___
Python tracker 

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

Re: Numpy array

[Rob Gaddi]

On 05/18/2018 09:50 PM, Sharan Basappa wrote:

This is regarding numpy array. I am a bit confused how parts of the array are 
being accessed in the example below.

1 import scipy as sp
2 data = sp.genfromtxt("web_traffic.tsv", delimiter="\t")
3 print(data[:10])
4 x = data[:,0]
5 y = data[:,1]

Apparently, line 3 prints the first 10 entries in the array
line 4 & 5 is to extract all rows but only 1st and second columns alone for x 
and y respectively.

I am confused as to how data[:10] gives the first 10 rows while data[:,0] gives 
all rows



Numpy ordering is [rows,columns,...].  Things you don't provide an 
explicit answer for are assumed to be "all", which in Python syntax is 
":".  The reason for THAT goes into how slices are constructed.


So your example 3 could also be written print(data[0:10,:]), which sets 
rows to the range starting with 0 and ending before 10, and columns to 
everything.


--
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: best way to remove leading zeros from a tuple like string

[Rodrigo Bistolfi]

>>> repr(tuple(int(i) for i in s[1:-1].split(',')))
'(128, 20, 8, 255, -1203, 1, 0, -123)'

2018-05-21 4:26 GMT-03:00 Peter Otten <__pete...@web.de>:

> bruceg113...@gmail.com wrote:
>
> > Looking over the responses, I modified my original code as follows:
> >
>  s = "(128, 020, 008, 255, -1203,01,-000, -0123)"
>  ",".join([str(int(i)) for i in s[1:-1].split(",")])
> > '128,20,8,255,-1203,1,0,-123'
>
> I think this looks better with a generator instead of the listcomp:
>
> >>> ",".join(str(int(i)) for i in s[1:-1].split(","))
> '128,20,8,255,-1203,1,0,-123'
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue5945] PyMapping_Check returns 1 for lists

[Guido van Rossum]

Change by Guido van Rossum :


--
nosy:  -gvanrossum

___
Python tracker 

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

[issue33591] ctypes does not support fspath protocol

[Robert]

Change by Robert :


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

Re: Spam levels.

[Grant Edwards]

On 2018-05-21, José María Mateos  wrote:
> On Mon, May 21, 2018 at 10:00:41AM +0200, m wrote:
>> I also almost stopped reading c.l.python, because of enormous spam
>> levels. Do I have any option to read it without spam, other than launch
>> my own filtering NNTP server and do whack the mole game for myself?
>> 
>> Maybe join forces and establish such server for public use?
>
> If you're willing to let NNTP access go, the mailing list works 
> perfectly fine and is virtually spam-free.

You can have both.  Point your NNTP client at news.gmane.org and
subscribe to gmane.comp.python.general.

That said, I never noticed any more spam on c.l.p than on the mailing
list.  I assume that's because my Usenet provider (Panix.com) filtered
it out.  I switched from Usenet to Gmane mainly because references
headers are bit more consistent on Gmane, so threading works somewhat
better.

[Regardless of whether I'm using Usenet or Gmane, I have slrn
configured to plonk all posts made from google.groups.]

-- 
Grant Edwards   grant.b.edwardsYow! My nose feels like a
  at   bad Ronald Reagan movie ...
  gmail.com

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

[issue25457] json dump fails for mixed-type keys when sort_keys is specified

[R. David Murray]

R. David Murray  added the comment:

I'm fairly certain (though not 100%, obviously :) that coercing first and then 
sorting would be accepted if someone wants to create a PR for this.

--
nosy: +r.david.murray
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

[issue25457] json dump fails for mixed-type keys when sort_keys is specified

[Christian Tanzer]

Christian Tanzer  added the comment:

Aaron Hall wrote at Sun, 20 May 2018 16:49:06 +:

> Now that dicts are sortable, does that make the sort_keys argument redundant?
>
> Should this bug be changed to "won't fix"?

https://bugs.python.org/issue25457#msg317216 is as good an answer as I
could give.

Considering that I openend the bug more than 2.5 years ago, it doesn't
really matter though.

--

___
Python tracker 

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

[issue33583] PyObject_GC_Resize() doesn't relink GCHead

[INADA Naoki]

INADA Naoki  added the comment:


New changeset 2b4ed5da1d599190c3be0084ee235b0a8f0a75ea by INADA Naoki (Miss 
Islington (bot)) in branch '3.7':
bpo-33583: Add note in PyObject_GC_Resize() doc (GH-7021)
https://github.com/python/cpython/commit/2b4ed5da1d599190c3be0084ee235b0a8f0a75ea


--

___
Python tracker 

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

Re: Spam levels.

[José María Mateos]

On Mon, May 21, 2018 at 10:00:41AM +0200, m wrote:
> I also almost stopped reading c.l.python, because of enormous spam
> levels. Do I have any option to read it without spam, other than launch
> my own filtering NNTP server and do whack the mole game for myself?
> 
> Maybe join forces and establish such server for public use?

If you're willing to let NNTP access go, the mailing list works 
perfectly fine and is virtually spam-free.

Cheers,

-- 
José María (Chema) Mateos
https://rinzewind.org/blog-es || https://rinzewind.org/blog-en
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue33589] Remove dummy member in GCHead

[INADA Naoki]

INADA Naoki  added the comment:

I grepped quickly and I can't find existing usage of anonymous union/struct.

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

[issue33589] Remove dummy member in GCHead

[INADA Naoki]

INADA Naoki  added the comment:

Oh,,, while even gcc 4.0 supported it, it is language spec from C11, not C99.

--

___
Python tracker 

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

[issue33589] Remove dummy member in GCHead

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I'm fine with an anonymous struct.  Is it standard C these days?

--

___
Python tracker 

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

[issue33589] Remove dummy member in GCHead

[INADA Naoki]

INADA Naoki  added the comment:

Make sense.

Then, what about using anonymous struct to make GC code more readable?

 typedef union _gc_head {
 struct {
 union _gc_head *gc_next;
 union _gc_head *gc_prev;
 Py_ssize_t gc_refs;
-} gc;
+};
 double dummy;  /* force worst-case alignment */
 } PyGC_Head;

All code like g->gc.gc_next will be like g->gc_next.

--

___
Python tracker 

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

[issue33583] PyObject_GC_Resize() doesn't relink GCHead

[miss-islington]

miss-islington  added the comment:


New changeset 3ccc31386da5f35f83756a265429831d650db731 by Miss Islington (bot) 
in branch '2.7':
bpo-33583: Add note in PyObject_GC_Resize() doc (GH-7021)
https://github.com/python/cpython/commit/3ccc31386da5f35f83756a265429831d650db731


--
nosy: +miss-islington

___
Python tracker 

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

[issue33581] Document "optional components that are commonly included in Python distributions."

[R. David Murray]

R. David Murray  added the comment:

As I understand it, we don't control or know what that list is, it depends on 
each distribution's policies.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue33591] ctypes does not support fspath protocol

[Robert]

Change by Robert :


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

___
Python tracker 

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

[issue33586] 2.7.15 missing release notes on download page

[Ned Deily]

Change by Ned Deily :


--
assignee: docs@python -> 
nosy: +benjamin.peterson

___
Python tracker 

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

Re: "Data blocks" syntax specification draft

[bartc]

On 20/05/2018 03:58, Mikhail V wrote:

I have made up a printable PDF with the current version
of the syntax suggestion.

https://github.com/Mikhail22/Documents/blob/master/data-blocks-v01.pdf

After some of your comments I've made some further
re-considerations, e.g. element separation should
be now much simpler.
A lot of examples with comparison included.


Comments, suggestions are welcome.


This is intended to be used inside actual Python programs?

In that case code is normally displayed in fixed pitch, as it would 
normally be viewed in a code editor, even if part of a document.


But I have to say it looks pretty terrible, and I can't see that it buys 
much over normal syntax.


The use of the funny /// symbol, and reserving identifiers t, L and d 
when following ///, is also a little naff.


(Note that lines starting // are interpreted as comment lines in C and 
C++ languages, and may be used by others too. Those used to see those as 
comments may get confused.)


It's not clear what ///. is for, or why it's necessary (presumably you 
have to use ///. /// instead of /// ///).


The ///d dictionary example is ambiguous: can you have more than one 
key:value per line or not? If so, it would look like this:


  ///d "a "b "c" "d" "e" "f"

so that the pairing is not clear.

You also seem to have more need of the "\" line continuation character 
in your syntax, because Python can do this:


   data = {

but you need:

   date = \
   ///

Or do you also allow: date = ///  with data following on the next line?


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

[issue33542] _ipconfig_getnode incorrectly selects a DUID as a MAC address

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Thank you for your contribution Zvi!

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 2.7

___
Python tracker 

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

Re: "Data blocks" syntax specification draft

[bartc]

On 21/05/2018 05:05, Chris Angelico wrote:

On Mon, May 21, 2018 at 2:00 PM, Mikhail V  wrote:



heaps! oh come on, youre making up again.


No, I'm not making it up. Just because the PDF works perfectly for
you, you assume that it'll work perfectly for everyone. That is not
the case, and that isn't my problem - it's your problem.


Perhaps the problem could well be at your end.

I don't remember having much trouble viewing PDFs, it's just a bit of a 
pain to do so (and I prefer to read them properly downloaded via the 
Adobe reader so that I can scroll in page mode, some extra steps).


I've just viewed a PDF on an old, low-spec Linux machine and it seemed 
fine, so it's not a Windows thing. (Can't access the OP's link for 
reasons unconnected with PDF.)


PDF seems to be universally used for all sorts of things (I used to have 
to print boarding passes via PDF; I doubt airlines wanted to alienate 
Linux users).


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

[issue33542] _ipconfig_getnode incorrectly selects a DUID as a MAC address

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset e9e2fd75ccbc6e9a5221cf3525e39e9d042d843f by Serhiy Storchaka in 
branch '3.6':
[3.6] bpo-33542: Ignore DUID in uuid.get_node on Windows. (GH-6922) (GH-7014)
https://github.com/python/cpython/commit/e9e2fd75ccbc6e9a5221cf3525e39e9d042d843f


--

___
Python tracker 

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

Re: "Data blocks" syntax specification draft

[Ned Batchelder]

On 5/19/18 10:58 PM, Mikhail V wrote:

I have made up a printable PDF with the current version
of the syntax suggestion.

https://github.com/Mikhail22/Documents/blob/master/data-blocks-v01.pdf

After some of your comments I've made some further
re-considerations, e.g. element separation should
be now much simpler.
A lot of examples with comparison included.


Comments, suggestions are welcome.



Mikhail, you have a completely different esthetic for syntax than the 
rest of the Python world.  Your proposal seems to have almost nothing in 
common with existing Python syntax.  Your approach to whitespace is 
different. You've ignored existing words (tuple, str) in favor of new 
shorthands (t, s).  You use semicolon and asterisk for something new.  
Parentheses enclosing strings!?


This is never going to be adopted as Python syntax. It's too different.

That's fine: make a new file format.  Write a library that can read and 
write this format.  Propose it to people, and get them using it.  We 
have xml, ini, json, yaml, and toml.  Now we can also have data blocks.


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

[issue33591] ctypes does not support fspath protocol

[Robert]

New submission from Robert :

Passing a non-str path which fulfills the new fspath-protcol (like a Path() 
object) to CDLL (or WinDLL, PyDLL, ...) a exception is returned.

--
components: ctypes
messages: 317230
nosy: mrh1997
priority: normal
severity: normal
status: open
title: ctypes does not support fspath protocol
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

[issue5945] PyMapping_Check returns 1 for lists

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
priority: high -> normal
versions: +Python 3.7, Python 3.8 -Python 3.5

___
Python tracker 

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

[issue5945] PyMapping_Check returns 1 for lists

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I propose an alternate PR 7029 which also adds other improvements to the 
documentation of mappings and sequences C API.

--

___
Python tracker 

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

[issue5945] PyMapping_Check returns 1 for lists

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
keywords: +patch
pull_requests: +6677

___
Python tracker 

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

Re: "Data blocks" syntax specification draft

[Chris Lindsay via Python-list]

So this is a syntax for defining large blocks of static data in-line with
code.

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. YAML comes to mind - it has minimal
punctuation, and whitespace as syntax, with little in the way of syntax
ambiguity since it isn't already a scripting language.

What use-case do you foresee for your proposed new format, that isn't
already (better) accomplished by using a separate structured
data/serialisation language?

On 21 May 2018 at 10:21, Steven D'Aprano <
steve+comp.lang.pyt...@pearwood.info> wrote:

> On Mon, 21 May 2018 01:28:51 +0300, Mikhail V wrote:
>
> > Source examples on
> > Github will force a crappy font and replace tabs.
>
>
> Is that supposed to convince us that using mandatory TABs is a good idea?
>
>
> --
> Steve
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>



-- 
Chris
Open Cosmos

Any opinions given above are my own.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue33263] Asyncio server enters an invalid state after a request with SO_LINGER

[Andrew Svetlov]

Change by Andrew Svetlov :


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

[issue33589] Remove dummy member in GCHead

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Short of adding a `tp_alignment`, though, I think we should not make things 
harder for the common cases.  This means we should probably keep the "double" 
member to ensure that extension types that have a "double" field in their 
object struct have the right alignment by default.  "long double" is much rarer 
and people who need it can workaround alignment issues by hand (for example by 
issuing memcpy() calls).

--

___
Python tracker 

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

[issue33263] Asyncio server enters an invalid state after a request with SO_LINGER

[Andrew Svetlov]

Andrew Svetlov  added the comment:


New changeset 7208bfb64b74f31f9704be3f01f26861c9cf092b by Andrew Svetlov in 
branch '3.6':
[3.6] bpo-33263: Fix FD leak in _SelectorSocketTransport (GH-6450) (#7025)
https://github.com/python/cpython/commit/7208bfb64b74f31f9704be3f01f26861c9cf092b


--

___
Python tracker 

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

[issue33589] Remove dummy member in GCHead

[Antoine Pitrou]

Antoine Pitrou  added the comment:

>From the linked changeset message:

> unless anyone knows of a platform where ssize_t is 4 bytes?

That's most 32-bit platforms, right?  Basically, size_t and ssize_t are 
pointer-sized except on some rare architectures.

> A more correct non-hacky alternative if any alignment issues are still found 
> would be to use a compiler specific alignment declaration on the structure 
> and determine which value to use at configure time.

AFAIU, the problem is not alignment of the PyGC_Head structure (it's always 
sufficiently aligned for its pointer-sized members) but alignment of the 
user-defined object that follows it.

The underlying issue IMO is we're trying to force a one-size-fits-all alignment 
for user-defined object structs that we know nothing about (but might contain 
something like a "long double" or, worse, some SIMD values).  Perhaps 
PyTypeObject should grow a `tp_alignment` field.

--
nosy: +gregory.p.smith, serhiy.storchaka, tim.peters

___
Python tracker 

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

[issue33583] PyObject_GC_Resize() doesn't relink GCHead

[miss-islington]

Change by miss-islington :


--
pull_requests: +6676

___
Python tracker 

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

[issue33583] PyObject_GC_Resize() doesn't relink GCHead

[miss-islington]

Change by miss-islington :


--
pull_requests: +6675

___
Python tracker 

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

[issue33583] PyObject_GC_Resize() doesn't relink GCHead

[miss-islington]

Change by miss-islington :


--
pull_requests: +6674

___
Python tracker 

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

[issue33583] PyObject_GC_Resize() doesn't relink GCHead

[INADA Naoki]

INADA Naoki  added the comment:


New changeset 1179f4b40f375af5c59cd4b6be9cc313fa0e1a37 by INADA Naoki in branch 
'master':
bpo-33583: Add note in PyObject_GC_Resize() doc (GH-7021)
https://github.com/python/cpython/commit/1179f4b40f375af5c59cd4b6be9cc313fa0e1a37


--

___
Python tracker 

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

[issue33238] AssertionError on await of Future returned by asyncio.wrap_future

[Andrew Svetlov]

Change by Andrew Svetlov :


--
versions: +Python 3.8 -Python 3.6

___
Python tracker 

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

[issue33238] AssertionError on await of Future returned by asyncio.wrap_future

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Raising `InvalidStateError` sounds perfect.

Would you make a pull request?

--

___
Python tracker 

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

[issue33544] Asyncio Event.wait() is a hold over from before awaitable, and should be awaitable

[Andrew Svetlov]

Change by Andrew Svetlov :


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

[issue33546] asyncio.Condition should become awaitable in 3.9

[Andrew Svetlov]

Andrew Svetlov  added the comment:

No, condition variables don't work this way.
The proper code looks like:

async with cond:
while not :
await cond.wait()


It cannot be collapsed to just `await cond`.

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

Re: Poor corporate communication culture - was Re: syntax oddities

[Steven D'Aprano]

On Sun, 20 May 2018 20:39:44 -0600, Michael Torrie wrote:

> Nine times out of ten, a top posted reply from a manager is a sure sign
> he hasn't bothered to read anything of what I actually wrote. Instead he
> just answers the question he thought I asked.

And the other one time out of ten, he's only read the first sentence.

Only half kidding.




-- 
Steve

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

Re: "Data blocks" syntax specification draft

[Steven D'Aprano]

On Mon, 21 May 2018 01:28:51 +0300, Mikhail V wrote:

> Source examples on
> Github will force a crappy font and replace tabs.


Is that supposed to convince us that using mandatory TABs is a good idea?


-- 
Steve

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

[issue33263] Asyncio server enters an invalid state after a request with SO_LINGER

[Andrew Svetlov]

Change by Andrew Svetlov :


--
pull_requests: +6673

___
Python tracker 

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

[issue23749] asyncio missing wrap_socket (starttls)

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Is the issue done?

--

___
Python tracker 

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

[issue33037] Skip sending/receiving after SSL transport closing

[Andrew Svetlov]

Change by Andrew Svetlov :


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

[issue30618] readlink for pathlib paths

[Dror Levin]

Change by Dror Levin :


--
nosy: +spatz

___
Python tracker 

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

[issue33523] loop.run_until_complete re-entrancy to support more complicated codebases in transition to asyncio

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Sorry, no.
The feature was requested many times but was constantly rejected.
By this, you are adding a BLOCKING call to your async function.
At least it leads to log warning about too long callback execution.

Moreover, I suspect that `run_until_complete` reentrancy requirement breaks the 
existing third-party loop implementations, not all loops can be fixed easily.

The last: calling blocking code from async code is the anti-pattern, asyncio 
explicitly discourages it.

You should convert all your stack to async functions and add sync stubs
when needed like

def sync_call(arg):
asyncio.get_event_loop().run_until_complete(async_call(arg))

Yuri, do you agree with me?

--

___
Python tracker 

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

[issue33263] Asyncio server enters an invalid state after a request with SO_LINGER

[Andrew Svetlov]

Andrew Svetlov  added the comment:


New changeset b8b800090ff0954117a26ffcb501307823f3d33a by Andrew Svetlov (Miss 
Islington (bot)) in branch '3.7':
bpo-33263: Fix FD leak in _SelectorSocketTransport (GH-6450) (#7022)
https://github.com/python/cpython/commit/b8b800090ff0954117a26ffcb501307823f3d33a


--

___
Python tracker 

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

Re: "Data blocks" syntax specification draft

[m]

W dniu 21.05.2018 o 06:00, Mikhail V pisze:
>> As Ian says, reStructuredText is the only supported format [1] for
>> PEPs, so you may as well just start using it straight away. GitHub
>> automatically renders it if you use a ".rst" extension on your file,
>> so the rendered form would be visible on the web.
> Ok. How is about images? this proposal will require a lot of images
> - otherwise people who read it are forced to copy-paste snippets
> into their code editors to understand how it may look in reality.
> 

I would say, that if proposition of your syntax requires images, then
it's bad syntax.

And re PDF - i opened that pdf with one click - hopefully I have
configured my thunderbird to that. And what do I see? Completely
unreadable code, because you used bizzare, non monospaced,  font to code
examples.

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

[issue32463] problems with shutil.py and os.get_terminal_size

[Nick McElwaine]

Nick McElwaine  added the comment:

Thankyou for clearing that up!

On 18 May 2018 at 13:05, Berker Peksag  wrote:

>
> Berker Peksag  added the comment:
>
> Thanks for the report. I agree with Eryk. os.get_terminal_size() is a
> low-level function. shutil.get_terminal_size() should be used as documented
> at https://docs.python.org/3/library/os.html#os.get_terminal_size
>
> shutil.get_terminal_size() is the high-level function which should
> normally be used, os.get_terminal_size is the low-level
> implementation.
>
> --
> nosy: +berker.peksag
> resolution:  -> not a bug
> stage:  -> resolved
> status: open -> closed
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue33590] sched.enter priority has no impact on execution

[Ronald Oussoren]

Ronald Oussoren  added the comment:

I don't think  there's a bug here: sched.enter schedules an event some time 
after the current time. The two calls to sched.enter are not at the same time, 
hence the priority is not used because the events are scheduled at different 
times.

--
nosy: +ronaldoussoren

___
Python tracker 

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

[issue33263] Asyncio server enters an invalid state after a request with SO_LINGER

[Andrew Svetlov]

Andrew Svetlov  added the comment:


New changeset a84d0b361a26c05c6fadc6640591ec3feee5bfb5 by Andrew Svetlov (Vlad 
Starostin) in branch 'master':
bpo-33263: Fix FD leak in _SelectorSocketTransport (GH-6450)
https://github.com/python/cpython/commit/a84d0b361a26c05c6fadc6640591ec3feee5bfb5


--

___
Python tracker 

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

[issue33263] Asyncio server enters an invalid state after a request with SO_LINGER

[miss-islington]

Change by miss-islington :


--
pull_requests: +6672

___
Python tracker 

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

Re: Spam levels.

[m]

W dniu 10.02.2018 o 15:57, C W Rose pisze:
> No other groups (in the limited set which I read) have the problem,
> and I don't understand why the spammers neither spam a range of
> groups, nor change their adddresses more frequently.  It may be
> that destroying comp.lang.python is their actual objective.
> 
> Either way, a depressing state of affairs.

The sad thing is, that your post is unseen, because of spam :S

I also almost stopped reading c.l.python, because of enormous spam
levels. Do I have any option to read it without spam, other than launch
my own filtering NNTP server and do whack the mole game for myself?

Maybe join forces and establish such server for public use?

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

[issue25457] json dump fails for mixed-type keys when sort_keys is specified

[zachrahan]

zachrahan  added the comment:

Well, "wontfix" would be appropriate in the context of deprecating the 
sort_keys option (over the course of however many releases) and documenting 
that the new procedure for getting JSON output in a specific order is to ensure 
that the input dict was created in that order.

Certainly for regression testing, sort_keys is no longer needed, but that's not 
the only reason people are using that option. (It's certainly not why I use the 
option -- my use stems from sort_keys improving human readability of the JSON.)

But outside of deprecating sort_keys wholesale, it is still a bug that 
sort_keys=True can cause an error on input that would otherwise be valid for 
json.dump[s].

--

___
Python tracker 

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

Re: best way to remove leading zeros from a tuple like string

[Peter Otten]

bruceg113...@gmail.com wrote:

> Looking over the responses, I modified my original code as follows:
> 
 s = "(128, 020, 008, 255, -1203,01,-000, -0123)"
 ",".join([str(int(i)) for i in s[1:-1].split(",")])
> '128,20,8,255,-1203,1,0,-123'

I think this looks better with a generator instead of the listcomp:

>>> ",".join(str(int(i)) for i in s[1:-1].split(","))
'128,20,8,255,-1203,1,0,-123'


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

Re: Python 3.6 causes error, python 3.5 does not.

[dieter]

Jim  writes:
> ...
> The problem is it runs fine if I use python 3.5. If I use python 3.6
> it opens the calc file then pops up a dialog saying
> "std::bad_alloc".

This looks like a C++ error message -- maybe from "calc".

It also looks quite severe (some memory allocation problem).
Therefore, it does not look likely that we can help you via this list.
I would use a C/C++ level debugger, to find out whether the message
come from the Python side (quite unlikely in my opinion) or from
"libreoffice".

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

Re: decorat{or,ion}

[dieter]

Mike McClain  writes:
> ...
> Thanks for the response, this is still a foreign language to me and I 
> need all
> the help I can get. I'm reading the docs, doing the tutorial again but 
> still have
> more questions than answers.
> If I understand what you said, 'taint necessarily so, I'll restate it 
> in psuedo
> code since I've little feel for python syntax yet.
>
> Let's forget buz().
>
> def bar(*args):
> (a,b,rest) = parseArgs(args)
> def baz(x):
> ...
> def bug(k,l,m):
> ...
> bug(foo(a), baz(b), rest)
>
> In 'def bar()', baz & bug are simply functions.

Indeed.

> Are they accessable outside bar?

No, unless they are explicitly passed out by "bar" (usually either as
function result or part thereof; but there are other ways as well).


> class bar(*args):
> (a,b,rest) = parseArgs(args)

I do not think that this would work.

While the "class" statement (defining a class)
has some similarity with the "def" statement (defining a function),
there are also differences.

In particular, the arguments in "class C()"
correspond to arguments passed to a function call, not the arguments
of a function definition. As one consequence, they are not made
visible in the class' namespace: your "parseArgs(args)" above
will not work (likely, you will already get an error before that point.

As a side note:
Associated with a class definition is a so called "metaclass"
(the association is usually implicit, but can be made explicit).
The arguments in "class C()" are passed as
one of the parameters in a metaclass call (other parameters are
the class name and the class dict). Thus, the "class" statement
effectively leads to a (function/method) call with the somewhat
prepared content of the class statement as parameters.

> def baz(x):
> ...
> ...
>
> In 'class bar()' I understand baz and bug should be named _baz_ , _bug_,
> if they're not expected to be called from outside bar but there's nothing
> to prevent one from doing so except manners.

It is a tacit convention that names starting with a "_" are in
various ways special:

__...__: are usually used for Python internal purposes and
  often treated very differently from other attributes.

  Usually, you should avoid to define such attributes
  yourself, unless you want to customize the
  associated Python behaviour.
  Otherwise, future Python versions might give a special
  meaning to your attribute and it may then no longer
  work as in previous Python versions.

__...: those attributes are mangled inside a class statement:
  the mangling consists of prepending "_".

  The purpose of this feature is to avoid name clashes
  in class inheritance. "__..." attribute are in some
  way "private" to the class (as far as the mangling
  ensures this), not (easily) seen be deriving classes.

   _...: provides a hint that this attribute/name is ment more for
  "local" rather then "public" use.

  There is nothing in Python that enforces this.


> Also they're now methods while
> still being functions and had to be declared 'def baz(self,x):'.

The precise details are as follows:

  The "def" always defines a function (whether or not it appears
  inside or outside of a "class" statement).

  If used inside a "class" statement, the function is put into
  the dictionary associated with the constructed class.

  If an attribute of a class or class instance is looked up
  in the "normal" way" (i.e. ".") and
  the result happens to be a function, then the function
  is not returned directly but wrapped into a method wrapper
  (containing both "" and the function).
  This means that the function is turned into a method
  during its access (not during its definition).

Usually, you access the functions in a "class" definition in the "normal
way" - and the result will behave as a method. Thus, you
can view (for simplicity) the corresponding definitions as method definitions
-- even though the transformation into a method only happens
on access to (and not on definition of) the function.


> Feel free to laugh if what I'm saying is nonsense in python.

Do not be worried.

> If I execute 'bar.baz(mu)',

As mentioned above, your example will not work. Let's modify
a bit:

  class C:
def baz(self, b):
  ...

  c = C()

If you use "C.baz", the result is in Python 2
a so called "unbound method":
it contains the class "C" and the function "baz".
If you want to call an "unbound method", you must
pass in all function arguments, including the first one. The call
will raise a "TypeError", when the first argument is not an instance
of the associated class.
In Python 3, "C.baz" returns the function "baz".

If you use "c.baz", the result is a so called "bound method":
it