[issue23551] IDLE to provide menu link to PIP gui.

[Aivar Annamaa]

Aivar Annamaa added the comment:

In case this issue becomes active again, I'm listing my design implemented in 
Thonny IDE (http://thonny.org) -- see the attached png.

If you decide same design is suitable for IDLE, then I'm happy to create a 
version of the dialog without Thonny dependencies. Here's the current source: 
https://bitbucket.org/plas/thonny/src/master/thonny/plugins/pip_gui.py?at=master=file-view-default

--
nosy: +Aivar.Annamaa
Added file: http://bugs.python.org/file46821/thonny_pip_gui.png

___
Python tracker 

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

Re: Rawest raw string literals

[Jussi Piitulainen]

Tim Chase writes:

> A number of tools use a custom quote-string:
>
> Bash:
>
>   cat <   "single and double" with \ and /
>   EOT

[snip]

> PS: yes, bash's does interpolate strings, so you still need to do
> escaping within, but the arbitrary-user-specified-delimiter idea still
> holds.

If you put any quote characters in the initial EOT, it doesn't. Quote
removal on the EOT determines the actual EOT at the end.

  cat <<"EOT"
  Not expanding any $amount here
  EOT
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue30114] json module: it is not possible to override 'true', 'false' values during encoding bool

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> rejected

___
Python tracker 

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

[issue30114] json module: it is not possible to override 'true', 'false' values during encoding bool

[Bob Ippolito]

Bob Ippolito added the comment:

Agreed, this does seem unnecessary. The library has been in active use for over 
a decade, and this is the first time I've seen this request. I would recommend 
preprocessing the data that you're going to encode if you have a need for this.

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

[issue30114] json module: it is not possible to override 'true', 'false' values during encoding bool

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I concur with Raymond.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue30122] Added missing archive programs and close option to Windows docs.

[Decorater]

Changes by Decorater :


--
title: Added missing things to Windows docs. -> Added missing archive programs 
and close option to Windows docs.

___
Python tracker 

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

[issue30122] Added missing things to Windows docs.

[Decorater]

Changes by Decorater :


--
pull_requests: +1349

___
Python tracker 

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

[issue30122] Added missing things to Windows docs.

[Decorater]

Changes by Decorater :


--
pull_requests: +1348

___
Python tracker 

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

[issue30122] Added missing things to Windows docs.

[Decorater]

Changes by Decorater :


--
pull_requests: +1347

___
Python tracker 

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

[issue30122] Added missing things to Windows docs.

[Decorater]

New submission from Decorater:

I realized the Windows docs lacked some information so I added it. I will try 
to create an cherry pick for 3.6 and 3.6 as well. Also if desired I could also 
see if it can be applied to the 2.7 branch as well.

--
assignee: docs@python
components: Documentation
messages: 292005
nosy: Decorater, docs@python
priority: normal
severity: normal
status: open
title: Added missing things to Windows docs.
versions: Python 3.5, 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

[issue30114] json module: it is not possible to override 'true', 'false' values during encoding bool

[Raymond Hettinger]

Raymond Hettinger added the comment:

Sorry, I think this is unnecessary feature creep.  The goal of the JSON module 
is to generate valid JSON for some semantically equivalent Python.  Wanting to 
turn *True* into the string "True" isn't in the spirit of the module and 
certainly not worth all the proposed code churn.  If this is really what you 
need (a somewhat exotic need at that), then I would recommend writing a 
recursive tree walker that replaces *True* nodes with "True" prior to outside 
of the JSON module.

--
assignee:  -> bob.ippolito
nosy: +bob.ippolito, rhettinger
versions: +Python 3.7 -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: Bigotry (you win, I give up)

[Rurpy via Python-list]

On 04/20/2017 01:46 PM, Ben Finney wrote:
>[...]
> I am not obliged to address every point of every post, and the absence
> of comment on any particular point is not generally to be read as full
> assent.

Certainly anyone is free to choose to ignore bigotry on the list,
because one agrees with it, or does not want to oppose the poster, 
or any other reason; that is a perfectly valid individual decision.

But that does not apply to an entire community.  When members of the 
community en masse react that way, and a few even laud the bigotry,
and still no protest, that is a condemnation of a community's ethics
and pretty indisputable proof the CoC is a tool, to be dragged out 
when convenient to repress unpopular opinion or posters and ignored 
when it interferes with propagating the popular view.

>>   "if you are going to have a CoC, it must be applied even-handedly."
> 
> I agree entirely with that.

Sadly, agreement is meaningless if ignored in practice.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[MRAB]

On 2017-04-21 01:11, Tim Chase wrote:

On 2017-04-20 16:40, Grant Edwards wrote:

How can there exist a "universal solution" even in theory?

There has to be some sort of "end of literal" terminator character
sequence.  That means there has to be some sort of escaping
mechanism when that "end of literal" sequence appears in the
literal itself.


A number of tools use a custom quote-string:

Bash:

   cat <
Perl 5 also does this.

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

Re: Rawest raw string literals

[Tim Chase]

On 2017-04-20 16:40, Grant Edwards wrote:
> How can there exist a "universal solution" even in theory?
> 
> There has to be some sort of "end of literal" terminator character
> sequence.  That means there has to be some sort of escaping
> mechanism when that "end of literal" sequence appears in the
> literal itself.

A number of tools use a custom quote-string:

Bash:

  cat 

[issue30104] Float rounding errors on AMD64 FreeBSD CURRENT Debug 3.x buildbot

[Ed Maste]

Changes by Ed Maste :


--
nosy: +emaste

___
Python tracker 

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

[issue29191] liblzma is missing from pcbuild.sln

[Steve Dower]

Steve Dower added the comment:


New changeset f60c9e54f501065f3be2a4cfb4c387dfa2f243a9 by Steve Dower (Segev 
Finer) in branch 'master':
bpo-29191: Add liblzma.vcxproj to pcbuild.sln and other missing entries (#1222)
https://github.com/python/cpython/commit/f60c9e54f501065f3be2a4cfb4c387dfa2f243a9


--

___
Python tracker 

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

[issue30121] Windows: subprocess debug assertion on failure to execute the process

[Segev Finer]

Changes by Segev Finer :


--
pull_requests: +1346

___
Python tracker 

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

[issue29191] liblzma is missing from pcbuild.sln

[Segev Finer]

Changes by Segev Finer :


--
pull_requests: +1345

___
Python tracker 

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

[issue30121] Windows: subprocess debug assertion on failure to execute the process

[Segev Finer]

New submission from Segev Finer:

subprocess triggers a debug assertion in the CRT on failure to execute the 
process due to closing the pipe *handles* in the except clause using os.close 
rather than .Close() (os.close closes CRT file descriptors and not handles).

In addition to that once this is fixed there is also a double free/close since 
we need to set `self._closed_child_pipe_fds = True` once we closed the handles 
in _execute_child so they won't also be closed in __init__.

To reproduce, do this in a debug build of Python:

import subprocess
subprocess.Popen('exe_that_doesnt_exist.exe', stdout=subprocess.PIPE)

See: https://github.com/python/cpython/pull/1218#discussion_r112550959

--
components: Library (Lib), Windows
messages: 292002
nosy: Segev Finer, eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows: subprocess debug assertion on failure to execute the process
type: behavior
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

[issue30104] Float rounding errors on AMD64 FreeBSD CURRENT Debug 3.x buildbot

[STINNER Victor]

Changes by STINNER Victor :


--
pull_requests: +1344

___
Python tracker 

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

Re: Rawest raw string literals

[MRAB]

On 2017-04-20 22:03, Mikhail V wrote:

On 20 April 2017 at 22:43, Random832  wrote:

On Thu, Apr 20, 2017, at 16:01, Grant Edwards wrote:

On 2017-04-20, MRAB  wrote:
> There _is_ a "universal solution"; it's called a Hollerith constant. :-)

Wow, I haven't seen one of those in a _long_ time -- probably about 45
years.  I think the first FORTAN implementation I used was WATFIV,
which had just introduced the character type. But, books/classes on
FORTRAN all still covered Hollerith constants.


The IMAP protocol uses a similar kind of construct (the length is
enclosed in braces)

Even ignoring the maintenance difficulty, I don't think it's possible to
syntax highlight something like that on most common editors.

The best solution I can think of is to have a text editor designed to
parse a string literal, spawn a nested editor with the unescaped
contents of that string literal, and then re-escape it back to place in
the code. If we had that, then we wouldn't even need raw strings.


Yes exactly, it would be cool to have such a satellite app
which can escape and unescape strings according to rules.
And which can also convert unicode literals to their ascii
analogues and back on the fly, this would very useful
for programming.
Probably it is a good idea to even include such thing
in Python package. So it would be a small standalone app
running parallel with text editor making it to copy paste strings.


I'm sure it's possible in, say, Emacs.

The editor that I use (EditPad Pro) can call external tools, so I could:

1. Select the string literal (easy when it is syntax-aware, so I can 
select all of the literal with 2 keypresses).


2. Call the external tool (1 keypress), to open, say, a simple tkinter app.

3. Edit the unescaped text (unescape with ast.literal_eval, re-escape 
with 'ascii').


4. Close the external tool, and the selection is replaced.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[Chris Angelico]

On Fri, Apr 21, 2017 at 7:37 AM, Stefan Ram  wrote:
> Mikhail V  writes:
>>But the less probable it is, the more complex or ugly would the tag
>>become.
>>E.g. curly braces {} seems to be much less frequent characters
>>for filenames and command line arguments.
>
>   When one uses brackets to delimit string literals,
>   on even can allow /nested/ brackets to be part of
>   the string without escapes, e.g., the literal
>
> [abc[def]ghi]
>
>   can stand for the string
>
> abc[def]ghi
>
>   . Only unpaired brackets then have to be escaped
>   (and occurences of the escape symbol at the end
>   of such a string).

If you're going to use brackets like that, I'd prefer a
multi-character delimiter:

[[[abcdef]]]

But you have to be careful about the nesting, because that makes it
difficult to create a string with an imbalanced set of delimiters.
You'll end up with messy and complicated edge cases.

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

[issue30104] Float rounding errors on AMD64 FreeBSD CURRENT Debug 3.x buildbot

[Dimitry Andric]

Dimitry Andric added the comment:

This is most likely the same issue we found in https://bugs.freebsd.org/216770, 
which was reported upstream to LLVM here: 
https://bugs.llvm.org//show_bug.cgi?id=31928, and resulted in a very long and 
not really productive discussion about whether type punning in this way is 
officially allowed, or a GNU extension.  I will gladly leave it to language 
lawyers. :)

In our case, easy fix was to use -fno-strict-aliasing, as we did here:
https://svnweb.freebsd.org/changeset/base/313706

--
nosy: +dim

___
Python tracker 

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

[issue30104] Float rounding errors on AMD64 FreeBSD CURRENT Debug 3.x buildbot

[STINNER Victor]

STINNER Victor added the comment:

> Why is -ffast-math being used? That seems like it's asking for trouble.

Sorry, my comment was unclear: I only tried to list all compiler options which 
have an impact on floating point numbers.

> So this is smelling like a compiler bug to me.

Right, I will report it to LLVM (clang).

--

___
Python tracker 

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

[issue30096] Update examples in abc documentation to use abc.ABC

[Eric Appelt]

Eric Appelt added the comment:

I created a PR to update the documentation to use this pattern and follow 
Raymond's suggestion of showing both ways to define an abc.

In order to make the examples comprehensible when read from beginning to end, I 
reordered the classes so that abc.ABC is described first.

--
nosy: +Eric Appelt

___
Python tracker 

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

[issue30096] Update examples in abc documentation to use abc.ABC

[Eric Appelt]

Changes by Eric Appelt :


--
pull_requests: +1343

___
Python tracker 

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

Re: Rawest raw string literals

[Mikhail V]

On 20 April 2017 at 22:43, Random832  wrote:
> On Thu, Apr 20, 2017, at 16:01, Grant Edwards wrote:
>> On 2017-04-20, MRAB  wrote:
>> > There _is_ a "universal solution"; it's called a Hollerith constant. :-)
>>
>> Wow, I haven't seen one of those in a _long_ time -- probably about 45
>> years.  I think the first FORTAN implementation I used was WATFIV,
>> which had just introduced the character type. But, books/classes on
>> FORTRAN all still covered Hollerith constants.
>
> The IMAP protocol uses a similar kind of construct (the length is
> enclosed in braces)
>
> Even ignoring the maintenance difficulty, I don't think it's possible to
> syntax highlight something like that on most common editors.
>
> The best solution I can think of is to have a text editor designed to
> parse a string literal, spawn a nested editor with the unescaped
> contents of that string literal, and then re-escape it back to place in
> the code. If we had that, then we wouldn't even need raw strings.

Yes exactly, it would be cool to have such a satellite app
which can escape and unescape strings according to rules.
And which can also convert unicode literals to their ascii
analogues and back on the fly, this would very useful
for programming.
Probably it is a good idea to even include such thing
in Python package. So it would be a small standalone app
running parallel with text editor making it to copy paste strings.


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

Re: Metaclass conundrum - binding value from an outer scope

[Lele Gaifax]

Skip Montanaro  writes:

> underlying = getattr(SomeOtherClass, a)
> def _meth(self, *args):
> return underlying(self._instance, *args)

Does

underlying = getattr(SomeOtherClass, a)
def _meth(self, *args, _underlying=underlying):
return _underlying(self._instance, *args)

help?

ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
l...@metapensiero.it  | -- Fortunato Depero, 1929.

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

Re: Rawest raw string literals

[Mikhail V]

On 20 April 2017 at 19:27, Chris Angelico  wrote:
> On Fri, Apr 21, 2017 at 2:26 AM,   wrote:
>> I find this:-
>>
>> s = r"ffmpeg -i  '\\server-01\D\SER_Bigl.mpg' "
>>
>> vastly superior.
>
> It's semantically different though. I don't know whether single quotes
> are valid in that context, on Windows.
>

For ffmpeg on Windows at least, both single and double quotes work equally.
So yes, if I keep the rule to use single quotes only inside commands
then I'd be fine with r"".
I simply don't like single quotes, and tend to use doble quotes
everywhere for better readability.

Well it is just somewhat unfortunate, because literals use
the quotes as a open/close tag, which are very common character in
strings. So the idea was to choose something that is not so
frequent and much less probable to appear in a string.
But the less probable it is, the more complex or ugly would the tag
become.
E.g. curly braces {} seems to be much less frequent characters
for filenames and command line arguments.


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

Re: Rawest raw string literals

[Random832]

On Thu, Apr 20, 2017, at 16:01, Grant Edwards wrote:
> On 2017-04-20, MRAB  wrote:
> > There _is_ a "universal solution"; it's called a Hollerith constant. :-)
> 
> Wow, I haven't seen one of those in a _long_ time -- probably about 45
> years.  I think the first FORTAN implementation I used was WATFIV,
> which had just introduced the character type. But, books/classes on
> FORTRAN all still covered Hollerith constants.

The IMAP protocol uses a similar kind of construct (the length is
enclosed in braces)

Even ignoring the maintenance difficulty, I don't think it's possible to
syntax highlight something like that on most common editors.

The best solution I can think of is to have a text editor designed to
parse a string literal, spawn a nested editor with the unescaped
contents of that string literal, and then re-escape it back to place in
the code. If we had that, then we wouldn't even need raw strings.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue29606] urllib FTP protocol stream injection

[Dong-hee Na]

Dong-hee Na added the comment:

I uploaded the PR which check invalid URL such as 
ftp://foo:bar%0d%0ainjec...@example.net/file.png

--
nosy: +corona10

___
Python tracker 

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

Re: Metaclass conundrum - binding value from an outer scope

[Peter Otten]

Skip Montanaro wrote:

> For various reasons, I have a class which delegates much functionality to
> a singleton instance of another class (exposed by pybind11) instead of
> inheriting from that class. So, the construction looks like this (this is
> in Python 2.7):
> 
> from someothermodule import SomeOtherClass as _SomeOtherClass
> 
> class SomeClass(object):
> _instance = None
> 
> def __init__(self):
> if self.__class__._instance is None:
> self._instance = _SomeOtherClass.instance()
> 
> def __getattr__(self, key):
> return getattr(self._instance, key)
> 
> ... and so on ...
> 
> If someone tries help(SomeClass) or dir(SomeClass) today, none of the
> attributes or docstrings defined in SomeOtherClass are shown.

If being helpful really is the only purpose of the metaclass you can 
implement a SomeClass.__dir__() method instead:

 def __dir__(self):
 names = dir(self._instance)
 # 
 return names 


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

Re: Rawest raw string literals

[Grant Edwards]

On 2017-04-20, MRAB  wrote:
> On 2017-04-20 17:40, Grant Edwards wrote:
>
>> There has to be some sort of "end of literal" terminator character
>> sequence.  That means there has to be some sort of escaping mechanism
>> when that "end of literal" sequence appears in the literal itself.
>> 
> There _is_ a "universal solution"; it's called a Hollerith constant. :-)

Wow, I haven't seen one of those in a _long_ time -- probably about 45
years.  I think the first FORTAN implementation I used was WATFIV,
which had just introduced the character type. But, books/classes on
FORTRAN all still covered Hollerith constants.

-- 
Grant Edwards   grant.b.edwardsYow! Look!  A ladder!
  at   Maybe it leads to heaven,
  gmail.comor a sandwich!

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

[issue29802] A possible null-pointer dereference in struct.s_unpack_internal()

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
pull_requests: +1342

___
Python tracker 

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

[issue29802] A possible null-pointer dereference in struct.s_unpack_internal()

[Serhiy Storchaka]

Serhiy Storchaka added the comment:


New changeset 7a113a0cbf545588d61286fcc0e89141cf211735 by Serhiy Storchaka in 
branch '3.6':
bpo-29802: Fix the cleaning up issue in PyUnicode_FSDecoder(). (#1217)
https://github.com/python/cpython/commit/7a113a0cbf545588d61286fcc0e89141cf211735


--

___
Python tracker 

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

[issue19764] subprocess: use PROC_THREAD_ATTRIBUTE_HANDLE_LIST with STARTUPINFOEX on Windows Vista

[Segev Finer]

Segev Finer added the comment:

OK Rietveld definitely punted on the git patch (I guess it's only for the old 
Mercurial repo, I don't think it actually even support Git...)

I will try re-submitting the patch as a PR so that it can be reviewed easily.

--

___
Python tracker 

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

[issue19764] subprocess: use PROC_THREAD_ATTRIBUTE_HANDLE_LIST with STARTUPINFOEX on Windows Vista

[Roundup Robot]

Changes by Roundup Robot :


--
pull_requests: +1341

___
Python tracker 

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

Re: Bigotry (you win, I give up)

[Ben Finney]

Like most people here, I think this thread has long ago served whatever
usefulness it will have. I'm not interested in continuing it.

I'll just respond to some direct questions, but don't take any lack of
response on particular points as agreement.

Rurpy via Python-list  writes:

> Rereading your post, I agree, you did not say anything at all about
> the old-people-cant-learn stereotype.
>
> So I apologize for saying you were ok with that.

Thank you, apology accepted.

> So at this point, you made a single attempt to claim there was no
> stereotyping based on national origin, a claim I refuted here [*1] and
> perhaps more clearly here [*2] neither of which there was a reply to.

And now we've both stated our cases, and others can judge the merits.
This particular debate isn't one I'm interested in pursuing further.

> And you explicitly acknowledge effectively a "no comment" response
> regarding an offensive a stereotype based on age? Is that a fair
> statement?

No. Simply not responding at all, since the charge was not even
addressed to me.

I am not obliged to address every point of every post, and the absence
of comment on any particular point is not generally to be read as full
assent.

We have to focus our responses, or they become even more lengthy and
unreadable than has already shown to be the case. That necessarily means
not responding to every point, even at the cost of omitting an objection
we might like to make.

>   "if you are going to have a CoC, it must be applied even-handedly."

I agree entirely with that.

-- 
 \“If the arguments in favor of atheism upset you, explain why |
  `\they’re wrong. If you can’t do that, that’s your problem.” |
_o__) —Amanda Marcotte, 2015-02-13 |
Ben Finney

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

Metaclass conundrum - binding value from an outer scope

[Skip Montanaro]

For various reasons, I have a class which delegates much functionality to a
singleton instance of another class (exposed by pybind11) instead of
inheriting from that class. So, the construction looks like this (this is
in Python 2.7):

from someothermodule import SomeOtherClass as _SomeOtherClass

class SomeClass(object):
_instance = None

def __init__(self):
if self.__class__._instance is None:
self._instance = _SomeOtherClass.instance()

def __getattr__(self, key):
return getattr(self._instance, key)

... and so on ...

If someone tries help(SomeClass) or dir(SomeClass) today, none of the
attributes or docstrings defined in SomeOtherClass are shown. It was almost
a straightforward exercise to write a metaclass which defines methods on
SomeClass which delegate to the underlying method on SomeOtherClass.

My problem is evaluating the return value of getattr(SomeOtherClass, attr)
immediately. The code in __new__ looks like this (somewhat abbreviated, but
only lightly):

class SomeMeta(type):
def __new__(cls, name, parents, dct):
for a in dir(SomeOtherClass):
if a[0] == "_": continue
underlying = getattr(SomeOtherClass, a)
def _meth(self, *args):
return underlying(self._instance, *args)
_meth.__doc__ = underlying.__doc__
dct[a] = _meth
return super(SomeMeta, cls).__new__(cls, name, parents, dct)

(Hopefully the indentation is correct. I have no Emacs on this stupid
Windows machine, so had to actually count my spaces.)

Suppose SomeOtherClass has methods m1, m2, and m3, processed in that order
coming out of the dir() call. All calls to SomeClass.m1, SomeClass.m2 and
SomeClass.m3 will wind up calling SomeOtherClass.m3, because the variable
"underlying" is evaluated late. I need it to be evaluated early (at the
time _meth is defined), when it has the value corresponding to attributes
"m1", "m2", or "m3". Thinking about it for a minute or two, I thought
functools.partial() might save my bacon, but that only partially applies
arguments. It won't work to bind the function name. I thought I might be
able to use it like this:

def _meth(self, underlying=None, *args):
return underlying(...)

then assign a partial function object to the dictionary:

dct[a] = functools.partial(_meth, underlying=underlying)

but that didn't seem to work (e.g., calling m1(1000) complained that int
objects have no _instance attribute, so clearly self was not getting set
properly), and it changes the runtime interface of the method (so it would
look different to people using SomeClass). Maybe I need to construct the
actual function assigned to dct[a] using types.FunctionType?

There's bound to be a way to do this, and I'm almost certainly going to
:dopeslap: myself when it's revealed, but I'm stuck on this. Any ideas?

Thx,

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

[issue19764] subprocess: use PROC_THREAD_ATTRIBUTE_HANDLE_LIST with STARTUPINFOEX on Windows Vista

[Segev Finer]

Segev Finer added the comment:

Oh LOL!!! I missed the fact that Python finally moved to GitHub!
Rebased the patch on top of the Git master XD (And removed accidentally 
committed code... sorry...)

I still submitted as a patch since I don't know if the infrastructure handles 
moving a patch to a PR well :P

--
Added file: 
http://bugs.python.org/file46820/windows-subprocess-close-fds-v6.patch

___
Python tracker 

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

Re: Rawest raw string literals

[MRAB]

On 2017-04-20 17:40, Grant Edwards wrote:

On 2017-04-20, Mikhail V  wrote:

On 20 April 2017 at 17:59, Grant Edwards  wrote:

On 2017-04-20, Mikhail V  wrote:

Quite often I need raw string literals for concatenating console commands.
I want to input them exactly as they are in python sources.

There is r"" string, but it is obviously not enough because e.g. this:
s = r"ffmpeg -i  "\\server-01\D\SER_Bigl.mpg" "


   s = r'ffmpeg -i  "\\server-01\D\SER_Bigl.mpg" '

Does that do what you want?


Yes but it still needs to watch out if there is no ' inside or vice
versa with " characters if use r"". I would like a universal
solution.


IOW, you want something that just reads your mind.

How can there exist a "universal solution" even in theory?

There has to be some sort of "end of literal" terminator character
sequence.  That means there has to be some sort of escaping mechanism
when that "end of literal" sequence appears in the literal itself.


There _is_ a "universal solution"; it's called a Hollerith constant. :-)
--
https://mail.python.org/mailman/listinfo/python-list

Re: Bigotry (you win, I give up)

[Rurpy via Python-list]

On 04/20/2017 09:25 AM, Rustom Mody wrote:
>[...]
> No one seems to have noticed who Rurpy is defending : Ranting Rick and Bart.
> Sheesh!
> A rhinocerous would have gossamer skin compared to these 'gentlemen'
> Sheesh² !

You are mistaken.  I am not defending Rick or Bart both of whom I am 
well aware are capable of speaking for themselves.

As I said in my first post, 
  "if you are going to have a CoC, it must be applied even-handedly."

> Also the obligatory Voltaire quote is: “I disapprove of what you say, but I 
> will 
> defend to the death your right to say It”

As I said (not that I am comparing myself to Voltaire)

| This is why you cannot create a forum where no offense is given 
| to anyone.  The best you can try to do is try to find some *tradeoff*
| that *balances* freedom of expression and offense.

If you think the current balance should be changed, fine.

My point is simply that whatever balance is chosen, it should apply
to all participants equally.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Bigotry (you win, I give up)

[Rurpy via Python-list]

On 04/19/2017 08:27 PM, Ben Finney wrote:
> Rurpy via Python-list  writes:
> 
>> You and Chris refused to find any fault with the use of the two
>> stereotypes under discussion one of which was "unable-to-learn old
>> people".
> 
> I expressed absolutely nothing on that topic, so I didn't “refuse to
> find any fault”. To claim “you said that is okay” is a bald untruth, I
> said no such thing.
> 
> You are pointing to *absence of a statement* on a topic and claiming
> that it is a “refusal to find any fault”.

Rereading your post, I agree, you did not say anything at all about
the old-people-cant-learn stereotype.

So I apologize for saying you were ok with that.

> By that logic, you have also “refused to find fault with” my neighbour's
> mistreatment of their child. How horrible of you!

No, not by that logic at all.  Never once did you mention your
neighbor or their child in the thread offering me the opportunity
to comment.  I mentioned both stereotypes in every post I made 
(at least where I mentioned either one explicitly).

> Except, that's not a claim I would make of you. I'll thank you not to do
> the same of others.

Yes, I will try to be more careful in the future.

So at this point, you made a single attempt to claim there was 
no stereotyping based on national origin, a claim I refuted here [*1]
and perhaps more clearly here [*2] neither of which there was a reply to.

And you explicitly acknowledge effectively a "no comment" response 
regarding an offensive a stereotype based on age?  Is that a fair 
statement?

So is it not fair to conclude that bigotry through the use of 
stereotypes in contravention of the CoC/Diversity statement is ok
here at least under some circumstances:

 * When the offender is a frequent or popular participant
 * When the stereotype agrees with a prejudice of most of participants
   here.

I repeat what I said in my first post [*3]:

  "if you are going to have a CoC, it must be applied even-handedly."


[*1] https://mail.python.org/pipermail/python-list/2017-April/721281.html
[*2] https://mail.python.org/pipermail/python-list/2017-April/721388.html
[*3] https://mail.python.org/pipermail/python-list/2017-April/721233.html
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Bigotry and hate speech on the python mailing list

[Rurpy via Python-list]

On 04/17/2017 03:39 AM, Marko Rauhamaa wrote:
>[...]

I meant to respond to this earlier but forgot to.  I'll respond
to the following part now since there seems to be some confusion
about my motives/intent.

> In my experience, the bar for banning participants is pretty high, and
> rightly so. Careless statements, insults or bigotry haven't been enough,
> but repeated, personal harassment of an individual have resulted in
> action.

I agree it should be high.  I did not ask for or expect any banning 
to occur and would oppose any such a proposal.  However, a public
note that use of such stereotypes are offensive and not consistent 
with the PSFs CoC/Diversity statement, a friendly reminder that the 
community frowns of that kind of expression regardless of the status 
of the person who made it, would be help maintain a common standard 
of posting decency.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[Arthur Havlicek]

No escaping is not something possible, in your suggested syntax ") is 
ambigous. E.g. raw("abcd")") is ambigous.


Any sequence delimited string involves escaping, the only thing that 
wouldnt would be size-defined strings but they are impractical.


Le 20/04/2017 à 18:03, Mikhail V a écrit :

On 20 April 2017 at 17:55, Chris Angelico  wrote:

On Fri, Apr 21, 2017 at 1:44 AM, Mikhail V  wrote:

What I think: why there is no some built-in function, for example like:
s = raw("ffmpeg -i  "\\server-01\D\SER_Bigl__"")

which would just need *one* quote sign in the beginning and on the end.
Would it be useful, what do you think? I think looks better than triple quote.
In the past there were quite a lot additions to string manipulation,
probably there is already something like this.

What would be the argument passed to this function?

ChrisA


Yeah that is right, I cant imagine how this would work.
But I think you get the idea- I'd want something dedicated
to input raw strings with cute syntax and *no* escaping
at all.


Mikhail


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

[issue29802] A possible null-pointer dereference in struct.s_unpack_internal()

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
pull_requests: +1340

___
Python tracker 

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

[issue29606] urllib FTP protocol stream injection

[Dong-hee Na]

Changes by Dong-hee Na :


--
pull_requests: +1339

___
Python tracker 

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

[issue30104] Float rounding errors on AMD64 FreeBSD CURRENT Debug 3.x buildbot

[Mark Dickinson]

Mark Dickinson added the comment:

Hmm. Just looked at dto5.c; nice work reducing it to something so simple.

This is looking a bit like either a strict-aliasing related problem, or a 
compiler bug, or both. My understanding of the "union trick" that dtoa.c uses 
is that it's well-defined under C99+TC3 (though that wasn't clear under the 
original C99), so it shouldn't be legitimate for an optimisation to cause 
different results to be produced.

So this is smelling like a compiler bug to me.

--

___
Python tracker 

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

[issue30085] Discourage operator.__dunder__ functions

[Terry J. Reedy]

Terry J. Reedy added the comment:

Raymond assigned the PR to himself, so I added him here as nosy and assignee.

--

___
Python tracker 

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

[issue30120] add new key words to keyword lib

[R. David Murray]

Changes by R. David Murray :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> keyword module missing async and await keywords

___
Python tracker 

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

Re: Rawest raw string literals

[eryk sun]

On Thu, Apr 20, 2017 at 5:27 PM, Chris Angelico  wrote:
> On Fri, Apr 21, 2017 at 2:26 AM,   wrote:
>> I find this:-
>>
>> s = r"ffmpeg -i  '\\server-01\D\SER_Bigl.mpg' "
>>
>> vastly superior.
>
> It's semantically different though. I don't know whether single quotes
> are valid in that context, on Windows.

On Windows, whether forward slash can be used as a path separator and
whether single quotes escape spaces and special characters depends on
the programs involved.

If you use the lpApplicationName parameter of CreateProcess (i.e.
`executable` for Popen), the system doesn't have to look at the
command line. Otherwise if the path of the executable in the command
line contains spaces, it needs to be quoted using double quotes;
single quotes have no special significance. If it has to search for
the executable, it calls SearchPath with the API's executable search
path (i.e. the directory of the calling application, the current
directory [in legacy mode], system directories, plus the PATH
environment variable) and .EXE as the optional file extension to
append.

Beyond that, the application can implement any command-line parsing
rules. In practice most programs use the CRT's argv parameter from the
`[w]main` entry point. Microsoft's CRT delimits arguments using
spaces; quotes arguments using double quotes; and escapes double
quotes using backslash [1].

If you're using the cmd.exe shell to run this, spaces and special
characters are escaped with double quotes, or with '^' outside of
quotes - except there's no way to completely escape "%" in a cmd.exe
command line (in a batch script, percent can be escaped by doubling it
as %%). If quoted, the path to the executable can use forward slash as
a path delimiter. cmd.exe implements its own custom search for the
executable, which includes the current directory (in legacy mode) and
PATH. It also tries appending all of the extensions in PATHEXT instead
of just .EXE. Since it uses the lpApplicationName parameter when it
calls CreateProcess, the system doesn't have to re-parse the command
line to locate the executable.

[1]: http://msdn.microsoft.com/en-us/library/17w5ykft.aspx
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue30104] Float rounding errors on AMD64 FreeBSD CURRENT Debug 3.x buildbot

[Mark Dickinson]

Mark Dickinson added the comment:

Why is -ffast-math being used? That seems like it's asking for trouble.

--

___
Python tracker 

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

[issue30120] add new key words to keyword lib

[Михайло Гавеля]

Changes by Михайло Гавеля :


--
pull_requests: +1338

___
Python tracker 

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

[issue30085] Discourage operator.__dunder__ functions

[Terry J. Reedy]

Terry J. Reedy added the comment:

My suggestion from the python-ideas thread:: replace the current

"The function names are those used for special class methods; variants without 
leading and trailing __ are also provided for convenience."

with

""Many function names are those used for special methods, minus the double 
underscores.  For backward compatibility, many of these have a variant with the 
double underscores kept.  We recommend using the dunderless form.  Note that 
operator.__add__(x, y), for instance, being the same as x + y, is not the same 
as x.__add__(y)."

Possibly add ", since the first two may result in calling y.__radd__(x)".



Raymond assigned the

--
assignee: docs@python -> rhettinger
nosy: +rhettinger

___
Python tracker 

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

[issue30120] add new key words to keyword lib

[Михайло Гавеля]

Changes by Михайло Гавеля :


--
components: Library (Lib)
nosy: Михайло Гавеля
priority: normal
severity: normal
status: open
title: add new key words to keyword lib
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

[issue29802] A possible null-pointer dereference in struct.s_unpack_internal()

[Serhiy Storchaka]

Serhiy Storchaka added the comment:


New changeset 40db90c1ce1a59d5f5f2894bb0ce3211bf27 by Serhiy Storchaka in 
branch 'master':
bpo-29802: Fix reference counting in module-level struct functions (#1213)
https://github.com/python/cpython/commit/40db90c1ce1a59d5f5f2894bb0ce3211bf27


--

___
Python tracker 

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

[issue30119] (ftplib) A remote attacker could possibly attack by containing the newline characters

[Dong-hee Na]

Changes by Dong-hee Na :


--
title: A remote attacker could possibly use this flaw to manipulate an FTP 
connection opened by a Python application -> (ftplib) A remote attacker could 
possibly attack by containing the newline characters

___
Python tracker 

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

[issue19764] subprocess: use PROC_THREAD_ATTRIBUTE_HANDLE_LIST with STARTUPINFOEX on Windows Vista

[Segev Finer]

Segev Finer added the comment:

Added the 5th version after another review by eryksun (In rietveld).

--
Added file: 
http://bugs.python.org/file46819/windows-subprocess-close-fds-v5.patch

___
Python tracker 

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

Re: How to obtain an up-to-date document of tkinter

[Terry Reedy]

On 4/20/2017 3:19 AM, Mok-Kong Shen wrote:

Am 20.04.2017 um 02:16 schrieb breamore...@gmail.com:

On Thursday, April 20, 2017 at 1:09:45 AM UTC+1, Mok-Kong Shen wrote:

How could one obtain an up-to-date document of tkinter. I ask this
question because apparently there are stuffs of tkinter that
worked in Python 3.5 but no longer in Python 3.6.1.




https://docs.python.org/3/library/tkinter.html

Can you please state what worked in 3.5 but doesn't in 3.6?


Yes. In Python V.3.5, I simply had the declaration:

from tkinter import *
and thereafter I could use in code lines e.g.:

messagebox.showerror()


That was not tkinter behavior.  And it was not the behavior in 2.x.

The above only worked (in 3.x) when running from IDLE, as an undesirable 
side-effect of imports made by IDLE's run.py before running user code. 
It did not work when running with Python directly, and should not have 
according to the language definition.  It was a bug in IDLE that I fixed 
for 3.5.3 (just checked), and 3.6.0.  See

https://bugs.python.org/issue25507
for an explanation.


However, in Python V.3.6.1,


and 3.6.0 and 3.5.3

I have to have the declaration: 
from tkinter import *

import tkinter.messagebox


as is normal for subpackages


and thereafter have to use:

tkinter.messagebox.showerror()


or

from tkinter import messagebox
messagebox.showerror(...)

or even

from tkinter.messagebox import showerror
showerror(...)

--
Terry Jan Reedy

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

Re: Bigotry and hate speech on the python mailing list

[jmp]

On 04/18/2017 02:48 AM, Ethan Furman wrote:

On 04/17/2017 03:23 PM, Ben Finney wrote:

So I will continue to treat all those topics equally: peripheral
comments on beliefs are just part of respectful human discourse, so long
as I'm respectful of the people who may hold such beliefs.


So you're okay with respectfully making people of faith feel unwelcome?

--
~Ethan~


I don't like signatures in general because I think it's an unsolicited 
statement of one's opinion, but whenever I meet one I don't agree with, 
I don't feel suddenly unwelcome.


However I fully support Ben's line of defense, people are worthy of 
respect, ideas not necessarily.


Whenever I'm saying anything stupid about python, I expect this list to 
react immediately, showing me how wrong I am. And usually this list 
delivers :) and I never felt disrespected...


cheers,

jm


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

[issue30119] A remote attacker could possibly use this flaw to manipulate an FTP connection opened by a Python application

[Dong-hee Na]

Changes by Dong-hee Na :


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

Re: [Python-ideas] Callable Enum values

[Ethan Furman]

On 04/20/2017 10:40 AM, Steve D'Aprano wrote:

On Fri, 21 Apr 2017 03:20 am, Ethan Furman wrote:



[redirecting back to the list]



Possibly the wrong list? This isn't Python-Ideas.


Woops!  Thanks.

--
~Ethan~

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

[issue30119] A remote attacker could possibly use this flaw to manipulate an FTP connection opened by a Python application

[Dong-hee Na]

Changes by Dong-hee Na :


--
pull_requests: +1337

___
Python tracker 

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

[issue30119] A remote attacker could possibly use this flaw to manipulate an FTP connection opened by a Python application

[Dong-hee Na]

New submission from Dong-hee Na:

It was discovered that the FTP client implementation in the Networking 
component of Python failed to correctly handle user inputs. 
A remote attacker could possibly use this flaw to manipulate an FTP connection 
opened by a Python application if it could make it access a specially crafted 
FTP URL.

See 
http://blog.blindspotsecurity.com/2017/02/advisory-javapython-ftp-injections.html

and https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-3533

I upload the patch for this issue.

--
messages: 291988
nosy: corona10
priority: normal
severity: normal
status: open
title: A remote attacker could possibly use this flaw to manipulate an FTP 
connection opened by a Python application
type: security

___
Python tracker 

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

[issue30104] Float rounding errors on AMD64 FreeBSD CURRENT Debug 3.x buildbot

[STINNER Victor]

STINNER Victor added the comment:

Much simpler test:

[haypo@freebsd ~/prog/python/master]$ clang40 -O1 dtoa5.c -o x && ./x
k=1
aadj=3.364
test ok
[haypo@freebsd ~/prog/python/master]$ clang40 -O2 dtoa5.c -o x && ./x
k=1
aadj=1.682
test FAILED: BUG!

--
Added file: http://bugs.python.org/file46818/dtoa5.c

___
Python tracker 

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

Re: [Python-ideas] Callable Enum values

[Steve D'Aprano]

On Fri, 21 Apr 2017 03:20 am, Ethan Furman wrote:

> [redirecting back to the list]


Possibly the wrong list? This isn't Python-Ideas.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: Rawest raw string literals

[Chris Angelico]

On Fri, Apr 21, 2017 at 2:26 AM,   wrote:
> I find this:-
>
> s = r"ffmpeg -i  '\\server-01\D\SER_Bigl.mpg' "
>
> vastly superior.

It's semantically different though. I don't know whether single quotes
are valid in that context, on Windows.

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

Re: [Python-ideas] Callable Enum values

[Ethan Furman]

[redirecting back to the list]

On 04/19/2017 11:15 PM, Stephan Hoyer wrote:

Ethan and Steven,

Thanks for your feedback on this one. I agree that it probably doesn't make 
sense for the standard library.

I'm still not really happy with any of the standard approaches for choosing a 
function based on an enum value -- they
all seem pretty verbose/ugly -- but clearly I'm bothered by this more than 
most, and the standard library is not a good
place for novel solutions.


I'm curious, what did you find ugly with:

class TestEnum(CallableEnum):

 @enum
 def hello(text):
 "a pleasant greeting"
 print('hello,', text)

 @enum
 def goodbye(text):
 print('goodbye,', text)

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

[issue30115] test_logging report reference leak

[Vinay Sajip]

Vinay Sajip added the comment:

I just did a git pull, then:

$ make distclean
$ ./configure --with-pydebug
$ make EXTRA_CFLAGS="-DPy_REF_DEBUG -DPy_TRACE_REFS"
$ ./python
Python 3.7.0a0 (heads/master:8f5cdfa, Apr 20 2017, 16:41:52) 
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>
$ ./python -m test.regrtest -R : test_logging
Run tests sequentially
0:00:00 [1/1] test_logging
beginning 9 repetitions
123456789
.
test_logging passed in 3 min 2 sec
1 test OK.

Total duration: 3 min 2 sec
Tests result: SUCCESS

I do sometimes get errors if I run again, e.g.

test_logging leaked [-164, 164, 0, 0] references, sum=0
test_logging leaked [-29, 31, 0, 0] memory blocks, sum=2

but results appear different every time, it seems. Is there any way to get them 
reproducibly?

--

___
Python tracker 

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

Re: Rawest raw string literals

[breamoreboy]

On Thursday, April 20, 2017 at 4:59:48 PM UTC+1, Grant Edwards wrote:
> On 2017-04-20, Mikhail V wrote:
> > Quite often I need raw string literals for concatenating console commands.
> > I want to input them exactly as they are in python sources.
> >
> > There is r"" string, but it is obviously not enough because e.g. this:
> > s = r"ffmpeg -i  "\\server-01\D\SER_Bigl.mpg" "
> 
>s = r'ffmpeg -i  "\\server-01\D\SER_Bigl.mpg" '
> 
> Does that do what you want?
> 
> -- 
> Grant Edwards   grant.b.edwardsYow! And then we could sit
>   at   on the hoods of cars at
>   gmail.comstop lights!

I find this:-

s = r"ffmpeg -i  '\\server-01\D\SER_Bigl.mpg' "

vastly superior.

Kindest regards.

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

[issue21842] Fix IDLE in unicodeless build

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


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

[issue21834] Fix a number of tests in unicodeless build

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


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

[issue21835] Fix Tkinter in unicodeless build

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


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

[issue21836] Fix sqlite3 in unicodeless build

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


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

[issue21837] Fix tarfile in unicodeless build

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


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

[issue21839] Fix distutils in unicodeless build

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


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

[issue21838] Fix ctypes in unicodeless build

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


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

[issue21841] Fix xml.sax in unicodeless build

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


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

[issue21843] Fix doctest in unicodeless build

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


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

[issue21845] Fix plistlib in unicodeless build

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


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

[issue21846] Fix zipfile in unicodeless build

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


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

[issue21848] Fix logging in unicodeless build

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


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

[issue21850] Fix httplib and SimpleHTTPServer in unicodeless build

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


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

[issue21851] Fix gettext in unicodeless build

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


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

[issue21852] Fix optparse in unicodeless build

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


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

[issue21854] Fix cookielib in unicodeless build

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
dependencies:  -Fix unicodeless build of Python
resolution:  -> rejected

___
Python tracker 

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

[issue21854] Fix cookielib in unicodeless build

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
dependencies: +Fix unicodeless build of Python
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

[issue21833] Fix unicodeless build of Python

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


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

Re: Rawest raw string literals

[Grant Edwards]

On 2017-04-20, Mikhail V  wrote:
> On 20 April 2017 at 17:44, Mikhail V  wrote:
>> Quite often I need raw string literals for concatenating console commands.
>> I want to input them exactly as they are in python sources.
>>
>> There is r"" string, but it is obviously not enough because e.g. this:
>> s = r"ffmpeg -i  "\\server-01\D\SER_Bigl.mpg" "
>>
>> is not valid.
>>
>> The closest I've found is triple quote literal:
>> s = r"""ffmpeg -i  "\\server-01\D\SER_Bigl__" """
>>
>> This is what I use now, still there is problem: last quote inside the string
>> needs escaping or a space character before closing triple quote,
>> otherwise there is again an error.
>>
>> What I think: why there is no some built-in function, for example like:
>> s = raw("ffmpeg -i  "\\server-01\D\SER_Bigl__"")
>>
>> which would just need *one* quote sign in the beginning and on the end.
>> Would it be useful, what do you think? I think looks better than triple 
>> quote.
>> In the past there were quite a lot additions to string manipulation,
>> probably there is already something like this.
>
> A function probably would not be possible to implement directly,
> but probably such a syntax for example:
> s = r"ffmpeg -i  "\\server-01\D\SER_Bigl.mpg""r
>
> i.e. an opening and closing "r" particle.

What do you do when the sting '"r' appears in the literal?

All you've done is change the literal terminating character sequence.
You still have to have a mechanism to escape it.

-- 
Grant Edwards   grant.b.edwardsYow! World War Three can
  at   be averted by adherence
  gmail.comto a strictly enforced
   dress code!

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

Re: Rawest raw string literals

[Grant Edwards]

On 2017-04-20, Mikhail V  wrote:
> On 20 April 2017 at 17:59, Grant Edwards  wrote:
>> On 2017-04-20, Mikhail V  wrote:
>>> Quite often I need raw string literals for concatenating console commands.
>>> I want to input them exactly as they are in python sources.
>>>
>>> There is r"" string, but it is obviously not enough because e.g. this:
>>> s = r"ffmpeg -i  "\\server-01\D\SER_Bigl.mpg" "
>>
>>s = r'ffmpeg -i  "\\server-01\D\SER_Bigl.mpg" '
>>
>> Does that do what you want?
>
> Yes but it still needs to watch out if there is no ' inside or vice
> versa with " characters if use r"". I would like a universal
> solution.

IOW, you want something that just reads your mind.

How can there exist a "universal solution" even in theory?

There has to be some sort of "end of literal" terminator character
sequence.  That means there has to be some sort of escaping mechanism
when that "end of literal" sequence appears in the literal itself.

-- 
Grant Edwards   grant.b.edwardsYow! I brought my BOWLING
  at   BALL -- and some DRUGS!!
  gmail.com

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

Re: Rawest raw string literals

[Chris Angelico]

On Fri, Apr 21, 2017 at 2:16 AM, Mikhail V  wrote:
> On 20 April 2017 at 17:59, Grant Edwards  wrote:
>> On 2017-04-20, Mikhail V  wrote:
>>> Quite often I need raw string literals for concatenating console commands.
>>> I want to input them exactly as they are in python sources.
>>>
>>> There is r"" string, but it is obviously not enough because e.g. this:
>>> s = r"ffmpeg -i  "\\server-01\D\SER_Bigl.mpg" "
>>
>>s = r'ffmpeg -i  "\\server-01\D\SER_Bigl.mpg" '
>>
>> Does that do what you want?
>>
>
> Yes but it still needs to watch out if there is no ' inside or vice versa
> with " characters if use r"". I would like a universal solution.

There's no universal solution, by definition. The nearest you'll get
is something like the PostgreSQL "dollar string":

$SomeTag$any text$SomeTag$

You can choose any tag you like for SomeTag and it'll match only the
corresponding tag, so this can be nested. But it's long and ugly,
especially when you don't need to actually nest it.

Python is not a shell scripting language, and trying to treat it as
one is usually going to get you into tangles like this. Much better,
IMO, is to treat Python as a scripting language, where higher-level
constructs like lists are the norm.

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

[issue30104] Float rounding errors on AMD64 FreeBSD CURRENT Debug 3.x buildbot

[STINNER Victor]

STINNER Victor added the comment:

> Still ok with clang 3.8 with -O1:

Sorry, you should read clang 4.0 here.

--

___
Python tracker 

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

[issue30104] Float rounding errors on AMD64 FreeBSD CURRENT Debug 3.x buildbot

[STINNER Victor]

STINNER Victor added the comment:

I created a test case: attached dtoa2.c.

Ok with GCC 6.3.1 (on Fedora 25) and clang 3.8 (on FreeBSD 11) with -O3:

haypo@selma$ gcc -O3 dtoa2.c -o x && ./x
text: 29865e170 -> float: 2.9865e+174
0x1.8265ea9f864bcp+579
{bc 64 f8 a9 5e 26 28 64}

[haypo@freebsd ~/prog/python/master]$ clang -O3 dtoa2.c -o x && ./x
text: 29865e170 -> float: 2.9865e+174
0x1.8265ea9f864bcp+579
{bc 64 f8 a9 5e 26 28 64}


Still ok with clang 3.8 with -O1:

[haypo@freebsd ~/prog/python/master]$ clang40 -O1 dtoa2.c -o x && ./x
text: 29865e170 -> float: 2.9865e+174
0x1.8265ea9f864bcp+579
{bc 64 f8 a9 5e 26 28 64}


Error with clang 4.0 using -O2 (on FreeBSD 11):

[haypo@freebsd ~/prog/python/master]$ clang40 -O2 dtoa2.c -o x && ./x
text: 29865e170 -> float: 2.9865e+174
0x1.8265ea9f864bdp+579<~ HERE, bd instead of bc
{bd 64 f8 a9 5e 26 28 64} <~ HERE, bd instead of bc

--
Added file: http://bugs.python.org/file46817/dtoa2.c

___
Python tracker 

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

Re: Rawest raw string literals

[Mikhail V]

On 20 April 2017 at 17:59, Grant Edwards  wrote:
> On 2017-04-20, Mikhail V  wrote:
>> Quite often I need raw string literals for concatenating console commands.
>> I want to input them exactly as they are in python sources.
>>
>> There is r"" string, but it is obviously not enough because e.g. this:
>> s = r"ffmpeg -i  "\\server-01\D\SER_Bigl.mpg" "
>
>s = r'ffmpeg -i  "\\server-01\D\SER_Bigl.mpg" '
>
> Does that do what you want?
>

Yes but it still needs to watch out if there is no ' inside or vice versa
with " characters if use r"". I would like a universal solution.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[Chris Angelico]

On Fri, Apr 21, 2017 at 2:03 AM, Mikhail V  wrote:
> On 20 April 2017 at 17:55, Chris Angelico  wrote:
>> On Fri, Apr 21, 2017 at 1:44 AM, Mikhail V  wrote:
>>> What I think: why there is no some built-in function, for example like:
>>> s = raw("ffmpeg -i  "\\server-01\D\SER_Bigl__"")
>>>
>>> which would just need *one* quote sign in the beginning and on the end.
>>> Would it be useful, what do you think? I think looks better than triple 
>>> quote.
>>> In the past there were quite a lot additions to string manipulation,
>>> probably there is already something like this.
>>
>> What would be the argument passed to this function?
>>
>> ChrisA
>
>
> Yeah that is right, I cant imagine how this would work.
> But I think you get the idea- I'd want something dedicated
> to input raw strings with cute syntax and *no* escaping
> at all.

Yep. It can't be a function; it has to be a piece of language syntax.

So then the question is: what language syntax is appropriate? And
honestly, I hardly ever need this kind of thing - partly because I
wouldn't call ffmpeg this way. I'd do it like this:

cmd = ["ffmpeg", "-i", r"\\server-01\D\SER_Bigl.mpg"]

with the separate arguments as, well, separate arguments. Far less
need for double escaping that way, and you can use different escaping
rules for different arguments if you need to. (Actually, I usually use
forward slashes, so even raw string lits are unnecessary.)

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

[issue29387] Tabs vs spaces FAQ out of date

[Mariatta Wijaya]

Changes by Mariatta Wijaya :


--
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: Rawest raw string literals

[Mikhail V]

On 20 April 2017 at 17:55, Chris Angelico  wrote:
> On Fri, Apr 21, 2017 at 1:44 AM, Mikhail V  wrote:
>> What I think: why there is no some built-in function, for example like:
>> s = raw("ffmpeg -i  "\\server-01\D\SER_Bigl__"")
>>
>> which would just need *one* quote sign in the beginning and on the end.
>> Would it be useful, what do you think? I think looks better than triple 
>> quote.
>> In the past there were quite a lot additions to string manipulation,
>> probably there is already something like this.
>
> What would be the argument passed to this function?
>
> ChrisA


Yeah that is right, I cant imagine how this would work.
But I think you get the idea- I'd want something dedicated
to input raw strings with cute syntax and *no* escaping
at all.


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

RE: Bigotry (you win, I give up)

[Deborah Swanson]

And the moral to the story is:

Don't worry. Be happy. And reach fot the stars (while still being
mindful of those around you).

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

Re: Rawest raw string literals

[Grant Edwards]

On 2017-04-20, Mikhail V  wrote:
> Quite often I need raw string literals for concatenating console commands.
> I want to input them exactly as they are in python sources.
>
> There is r"" string, but it is obviously not enough because e.g. this:
> s = r"ffmpeg -i  "\\server-01\D\SER_Bigl.mpg" "

   s = r'ffmpeg -i  "\\server-01\D\SER_Bigl.mpg" '

Does that do what you want?

-- 
Grant Edwards   grant.b.edwardsYow! And then we could sit
  at   on the hoods of cars at
  gmail.comstop lights!

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

Re: Rawest raw string literals

[Mikhail V]

On 20 April 2017 at 17:44, Mikhail V  wrote:
> Quite often I need raw string literals for concatenating console commands.
> I want to input them exactly as they are in python sources.
>
> There is r"" string, but it is obviously not enough because e.g. this:
> s = r"ffmpeg -i  "\\server-01\D\SER_Bigl.mpg" "
>
> is not valid.
>
> The closest I've found is triple quote literal:
> s = r"""ffmpeg -i  "\\server-01\D\SER_Bigl__" """
>
> This is what I use now, still there is problem: last quote inside the string
> needs escaping or a space character before closing triple quote,
> otherwise there is again an error.
>
> What I think: why there is no some built-in function, for example like:
> s = raw("ffmpeg -i  "\\server-01\D\SER_Bigl__"")
>
> which would just need *one* quote sign in the beginning and on the end.
> Would it be useful, what do you think? I think looks better than triple quote.
> In the past there were quite a lot additions to string manipulation,
> probably there is already something like this.

A function probably would not be possible to implement directly,
but probably such a syntax for example:
s = r"ffmpeg -i  "\\server-01\D\SER_Bigl.mpg""r

i.e. an opening and closing "r" particle.
-- 
https://mail.python.org/mailman/listinfo/python-list