from:"paul"



Paul Sokolovsky  added the comment:

> exec() function is currently quite clear

A recent case: https://bugs.python.org/issue38316, co_stacksize was quite clear 
what it is. Turned out, a bug in the documentation (likely, just someone forgot 
to update it to the actual code). That's just one case, there're tons of bugs 
in the docs.

--

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

[issue32615] Inconsistent behavior if globals is a dict subclass



Paul Sokolovsky  added the comment:

> Namespace performances are really critical for overall Python performances.

Yeah, that's why I'd like for myself and other people to make it easy to 
explore the behavior of namespace lookups, to see how to optimize them.


> You're free to fork Python and modify the C code to implement your use case, 
> to study Python internals.

Thanks, already done. I'm now looking for a way to share those studies with 
other people, who won't patch and compile CPython. So, no worries, I've already 
lost, I need that fix yesterday, in actual versions of CPython deployed around 
the world. The rest if just idea that bugs which aren't fixed, persist; and the 
very interesting case of decision making by CPython core developers.

--

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

[issue32615] Inconsistent behavior if globals is a dict subclass



Paul Sokolovsky  added the comment:

> Paul: you're are in front of 3 core developers who are rejecting your feature 
> request.

But no, it's not my feature request. There were 2 tickets by at least 2 people. 
I just saw my case to be similar to cases of those people, so instead of 
creating duplicate bug reports, I chimed in, to show the general issue: various 
name-related opcodes don't treat namespace objects consistently.

And if I'm in front on 3 core developers here, then only because someone's 
Rubber Ducky (https://en.wikipedia.org/wiki/Rubber_duck_debugging) took a good 
vacation. Because I may imagine following "debugging session":

- Hey Ducky, some time ago I hacked on one project. As you know, I'm a core 
developer, so I kinda can add things on my whim, so I added some stuff to 
CPython core for that project, not consistent, not complete. Since then, I lost 
interest in my project, and as you can imagine, couldn't care less about the 
code in the core. The problem? It was almost 8 years ago. People discovered 
those features, and came to use on them. Not only that, they raise heads and 
demand it to be implemented more thoroughly and consistently. So, don't you 
think now would be good time to punish them and just rip that code out?

- You say how could I possible to do that on my own? No worries, I have 2 more 
buddies vouching for me, we core developers never let each other down.

- You're saying that removing features after 8 years is problematic? No 
worries, we can always say it was a regression from just 3 years ago.

- Hey Ducky, there's a more problem still, there's a particularly obnoxious 
dude, who initially tried to argue need for adding a feature based on my 8-year 
old code. If we support stuff in LOAD_GLOBAL, he says, then it should be piece 
of cake to support it in STORE_GLOBAL, which is called much less frequently. 
But we got him into the cold with a news of removal that 8-year code. Still he 
can't calm down, and changing tactics arguing that due to the way that globals 
are used at the module level (as locals too), then STORE_GLOBAL should behave 
consistently with STORE_NAME, tossing some pretty simple exec() code showing 
inconsistency. Should we just ignore him, or go for total punishment and make 
it "consistent" just the same as above, by removing support in STORE_NAME, 
instead of adding to STORE_GLOBAL? Now, that code is 16 years old. Do you think 
we can go for a twist like that?

--

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

[issue32615] Inconsistent behavior if globals is a dict subclass



Paul Sokolovsky  added the comment:

> you ask to modify Python so you can pass dict subclasses as namespaces and 
> expect CPython to respect the mapping protocol

But no, per your own account, you made noticeable, though not complete, code 
changes in that direction. The only thing I'm saying "now that it's all there, 
it's only logical to fix the missing parts, about which people report issues". 
While you suddenly come up with "alternative" solution - throw it all away.

And I always just took your word for it, but now did some git logging/blaming. 
So, LOAD_GLOBAL handling of dict subclasses was introduced by you in 
https://github.com/python/cpython/commit/b0b224233e481d979430a54d257d871424ff19fb
 , in 2012, almost 8 years ago. 

And what about STORE_NAME handling? I traced that to 
https://github.com/python/cpython/commit/214b1c3aaea3e83302df9ea37a37b3c7548b92b1
 of 2004.

--

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

[issue32615] Inconsistent behavior if globals is a dict subclass



Paul Sokolovsky  added the comment:

Ok, so the patch for my usecase (STORE_GLOBAL) is vividly trivial, so to go 
thru the full circle, I posted it: https://github.com/python/cpython/pull/18033 
.

--

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

[issue36220] LOAD_NAME and LOAD_GLOBAL, STORE_GLOBAL handle dict subclasses for globals() differently



Change by Paul Sokolovsky :


--
pull_requests: +17429
pull_request: https://github.com/python/cpython/pull/18033

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

[issue32615] Inconsistent behavior if globals is a dict subclass



Paul Sokolovsky  added the comment:

s/only our own usecase/only your own usecase/ (missing "y" typo)

--

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

[issue32615] Inconsistent behavior if globals is a dict subclass



Paul Sokolovsky  added the comment:

> Later, I closed my pysandbox beause it was "broken by design":
https://lwn.net/Articles/574215/

Thanks for the link, insightful. Still unclear, by design of what it's broken 
;-).


> Paul Sokolovsky wrote in bpo-36220 than his idea is also to implement a 
> sandbox

Depends on the definition of "sandbox". If it's "But I was contacted by
different companies interested to use pysandbox in production on their
web application.  So I think that there is a real need to execute
arbitrary untrusted code." (re: https://lwn.net/Articles/574323/). Then no, I 
definitely not developing such a "sandbox".

If by "sandbox" you mean "ability to override some namespacing rules used by 
Python", then yep, I, and other folks (according to these >1 issue reports) 
interested in that. It's unclear why demise of your particular project should 
affect all other possible projects interested in dealing with namespacing 
matters. I for example interested in study of some properties of corpus of 
Python code. I can understand your claim that you "own" the partial features 
you introduced, but claiming them to be useful for only our own usecase is 
somewhat ..., well, short-sighted, just as claiming that all such uses should 
cease and desist is as insightful as claiming that, for example, list 
comprehensions are useless because you faced a case when one needs to be 
rewritten as explicit loop.

> IMHO we should reject dict subclasses to make Python (especially ceval.c) 
> more efficient.

I'm afraid efficiency story for CPython is irrecoverably lost, unless someone 
secretly works on adding JIT to it, but as we know, JIT work happily happens 
outside of it, in multiples. CPython still can either serve as a common 
platform for prototyping and experimentation, or complicate that by a committee 
fiat. Because the current situation is that CPython is too dynamic to be 
"slow", but not enough dynamic to perform useful instrumentation easily. For 
example, to comfortably do study on the proportions of actual usage of various 
"overdynamic" features.

--

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

[issue39318] NamedTemporaryFile could cause double-close on an fd if _TemporaryFileWrapper throws

2020-01-16 Thread Paul Ollis



Paul Ollis  added the comment:

> I thought that if this raises a (normal) exception, it always means that it
> did not have overtaken the `fd`, i.e. never results in an unreferenced file
> object which has taken ownership of `fd`.

The current CPython implementation does not guard against this happening. Some
incorrect combinations of arguments will definitely cause the problem. It is
also possible that it could occur under other circumstances.

> It this is not true right now, you are right that this is problematic. But
> this should be simple to fix on the CPython side, right? I.e. to make sure
> whenever some exception is raised here, even if some temporary file object
> already was constructed, it will not close `fd`. It should be consistent in
> this behavior, otherwise indeed, the semantics are broken.

I agree. I think it should be fairly simple to fix for CPython.

--

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

[issue39318] NamedTemporaryFile could cause double-close on an fd if _TemporaryFileWrapper throws

2020-01-15 Thread Paul Ollis



Paul Ollis  added the comment:

I think it is worth pointing out that the semantics of 

f = ``open(fd, closefd=True)`` 

are broken (IMHO) because an exception can result in an unreferenced file
object that has taken over reponsibility for closing the fd, but it can
also fail without creating the file object.

Therefore it should be considered a bad idea to use open in this way. So
NamedTemporaryFile should take responsibility for closing the fd; i.e. it
should used closefd=False.

I would suggest that NamedTemporaryFile's code should be:

try:
file = _io.open(fd, mode, buffering=buffering, closefd=False,
newline=newline, encoding=encoding, errors=errors)
return _TemporaryFileWrapper(file, name, delete)
except BaseException:
_os.close(fd)
try:
_os.unlink(name)
except OSError:
pass  # On windows the file will already be deleted.
raise

And '_os.close(self.file.fileno())' should be added after each of the two calls
to 'self.file.close()' in _TemporaryFileCloser.

Some notes on the design choices here.

1. The exception handling performs the close *before* the unlink because:

   - That is the normal order that people expect.
   - It is most important that the file is closed. We cannot rule out the 
 possibility of the unlink raising an exception, which could leak the fd.

2. BaseException is caught because we should not leak a file descriptor for
   KeyboardInterrupt or any other exception.

3. It is generally good practice to protect os.unlink with a try ... except
   OSError. So I think this is an appropriate way to prevent the Windows
   specific error. 

   It will also suppress some other, rare but possible, errors. I think that
   this is legitimate behaviour, but it should be documented.

--
nosy: +paul_ollis

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

[issue39280] Don't allow datetime parsing to accept non-Ascii digits

2020-01-10 Thread Paul Ganssle


Paul Ganssle  added the comment:

> Yes, but not within the same format. If someone were to choose the format 
> '2014-04-10T24:00:00', they would have a reasonable expectation that there is 
> only one unique string that corresponds with that datetime

That's a particularly bad example, because it's exactly the same as another 
string with the exact same format:

  2014-04-11T00:00:00

Since ISO 8601 allows you to specify midnight (and only midnight) using 
previous day + 24:00. Admittedly, that is the only ambiguity I know of offhand 
(though it's a huge spec) *for a given format*, but also ISO 8601 does not 
really have a concept of format specifiers, so it's not like there's a way to 
unambiguously specify the format you are intending to use.

Either way, I think we can explicitly dispense with "there will be an exact 
mapping between a given (format_str, datetime_str) pair and the datetime it 
produces" as a goal here. I can't think of any good reason you'd want that 
property, nor have we made any indication that I can see that we provide it 
(probably the opposite, since there are some formats that explicitly ignore 
whitespace).

> Okay, since it seems like I'm the only one who wants this change, I'll let it 
> go. Thanks for your input.

I wouldn't go that far. I think I am +0 or +1 on this change, I just wanted to 
be absolutely clear *why* we're doing this. I don't want someone pointing at 
this thread in the future and saying, "Core dev says that it's a bug in their 
code if they don't follow X standard / if more than one string produces the 
same datetime / etc".

I think the strongest argument for making this or a similar change is that I'm 
fairly certain that we don't have the bandwidth to handle internationalized 
dates and I don't think we have much to gain by doing a sort of half-assed 
version of that by accepting unicode transliterations of numerals and calling 
it a day. I think there are tons of edge cases here that could bite people, and 
if we don't support this *now* I'd rather give people an error message early in 
the process and try to point people at a library that is designed to handle 
datetime localization issues. If all we're going to do is switch [0-9] to \d 
(which won't work for the places where it's actually [1-9], mind you), I think 
people will get a better version of that with something like:

  def normalize_dt_str(dt_str):
  return "".join(str(int(x)) if x.isdigit() else x
 for x in dt_str)

There are probably more robust and/or faster versions of this, but it's 
probably roughly equivalent to what we'd be doing here *anyway*, and at least 
people would have to opt-in to this.

I am definitely open to us supporting non-ASCII digits in strptime if it would 
be useful at the level of support we could provide, but given that it's 
currently broken for any reasonable use case and as far as I know no one has 
complained, we're better off resolving the inconsistency by requiring ASCII 
digits and considering non-ASCII support to be a separate feature request.

CC-ing Inada on this as unicode guru and because he might have some intuition 
about how useful non-ASCII support might be. The only place I've seen non-ASCII 
dates is in Japanese graveyards, and those tend to use Chinese numerals (which 
don't match \d anyway), though Japanese and Korean also tends to make heavier 
use of "full-width numerals" block, so maybe parsing something like 
"２０２０－０２－０２" is an actual pain point that would be improved by this change 
(though, again, I suspect that this is just the beginning of the required 
changes and we may never get a decent implementation that supports unicode 
numerals).

--
nosy: +inada.naoki

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

[issue39280] Don't allow datetime parsing to accept non-Ascii digits

2020-01-09 Thread Paul Ganssle

Paul Ganssle added the comment:

I don't love the inconsistency, but can you elaborate on the actual *danger*
posed by this? What security vulnerabilities involve parsing a datetime using a
non-ascii digit?

The reason that `fromisoformat` doesn't accept non-ASCII digits is actually
because it's the inverse of `datetime.isoformat`, which never *emits* non-ASCII
digits. For `strptime`, we're really going more for a general specifier for
parsing datetime strings in a given format. I'll note that we do accept any
valid unicode character for the date/time separator.

>From my perspective, there are a few goals, some of which may be in conflict
>with the others:

1. Mitigating security vulnerabilities, if they exist.
2. Supporting international locales if possible.
3. Improving consistency in the API.

If no one ever actually specifies datetimes in non-ascii locales (and this
gravestone that includes the date in both Latin and Chinese/Japanese characters
seems to suggest otherwise:
https://jbnewall.com/wp-content/uploads/2017/02/LEE-MONUMENT1-370x270.jpg ),
then I don't see a problem dropping our patchy support, but I think we need to
carefully consider the backwards compatibility implications if we go through
with that.

One bit of evidence in favor of "no one uses this anyway" is that no one has
yet complained that apparently this doesn't work for "%d" even if it works for
"%y", so presumably it's not heavily used. If our support for this sort of
thing is so broken that no one could possibly be using it, I suppose we may as
well break it all the way, but it would be nice to try and identify some
resources that the documentation can point to for how to handle international
date parsing.

> Note the "unique and unambiguous". By accepting non-Ascii digits, we're
> breaking the uniqueness requirement of ISO 8601.

I think in this case "but the standard says X" is probably not a very strong
argument.
Even if we were coding to the ISO 8601 standard (I don't think we claim to be,
we're just using that convention), I don't really know how to interpret the
"unique" portion of that claim, considering that ISO 8601 specifies dozens of
ways to represent the same datetime. Here's an example from [my
`dateutil.parse.isoparse` test
suite](https://github.com/dateutil/dateutil/blob/110a09b4ad46fb87ae858a14bfb5a6b92557b01d/dateutil/test/test_isoparser.py#L150):

```
'2014-04-11T00',
'2014-04-10T24',
'2014-04-11T00:00',
'2014-04-10T24:00',
'2014-04-11T00:00:00',
'2014-04-10T24:00:00',
'2014-04-11T00:00:00.000',
'2014-04-10T24:00:00.000',
'2014-04-11T00:00:00.00',
'2014-04-10T24:00:00.00'
```

All of these represent the exact same moment in time, and this doesn't even get
into using the week-number/day-number configurations or anything with time
zones. They also allow for the use of `,` as the subsecond-component separator
(so add 4 more variants for that) and they allow you to leave out the dashes
between the date components and the colons between time components, so you can
multiply the possible variants by 4.

Just a random aside - I think there may be strong arguments for doing this even
if we don't care about coding to a specific standard.

--
nosy: +p-ganssle

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

[issue39255] Windows and Unix run-time differences

2020-01-08 Thread Paul Moore



Paul Moore  added the comment:

For me, I headed straight for "Sharing state between processes" and the "Shared 
memory" object. That's probably because I was reviewing someone else's code, 
rather than writing my own, but nevertheless when coding I do tend to dive 
straight for the section that describes what I want to do, and miss "overview" 
type discussions.

The way the shared memory object is described, it reads that it is just that - 
shared. And so I'd assume that if a shared memory object is in multiple 
processes in a pool, it would be the *same* shared memory region, and the value 
would be accessible from all the processes.

>From there, for me at least, it's easy to proceed to the mistake of thinking 
>that the global initialisation of the x and y variables creates the *same* 
>shared memory objects in each process in the pool. Clearly it doesn't, hence 
>this is "not a bug" but for me it's an easy mistake to make.

Maybe it would be enough just to add a comment to the shared memory object 
documentation that said "every shared memory object is independent - there is 
no way to create a reference to the same shared memory object in multiple 
processes, instead you need to create the object in one process and pass it to 
all of the others". That would probably have made me stop and think long enough 
to not make the mistake I did.

--

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

[issue39255] Windows and Unix run-time differences

2020-01-08 Thread Paul Moore



Paul Moore  added the comment:

Agreed it's not a bug, but I will say it took me a while to work out *why* it's 
not a bug (namely, that even though the OP is using shared memory values, the 
code relies on fork semantics to share the two Value objects that *reference* 
the shared memory).

It would be worth adding a note to the documentation on shared memory values at 
https://docs.python.org/3.8/library/multiprocessing.html#sharing-state-between-processes
 to make it clearer that it's the user's responsibility to make sure the Value 
object is passed to every subprocess that wants to interact with it.

--

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

[issue30717] Add unicode grapheme cluster break algorithm

2020-01-06 Thread Paul Ganssle



Paul Ganssle  added the comment:

> Oh, also, if y'all are fine with binding to Rust (through a C ABI) I'd love 
> to help y'all use unicode-segmentation, which is much less work that pulling 
> in ICU. Otherwise if y'all have implementation questions I can answer them. 
> This spec is kinda tricky to implement efficiently, but it's not super hard.

Is the idea here that we'd take on a new dependency on the compiled 
`unicode-segmentation` binary, rather than adding Rust into our build system? 
Does `unicode-segmentation` support all platforms that CPython supports? I was 
under the impression that Rust requires llvm and llvm doesn't necessarily have 
the same support matrix as CPython (I'd love to be corrected if I'm wrong on 
this).

(Note: I don't actually know what the process is for taking on new dependencies 
like this, just trying to point at one possible stumbling block.)

--

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

[issue32615] Inconsistent behavior if globals is a dict subclass



Paul Sokolovsky  added the comment:

> I agree with Terry, the moment you pass a dict subclass to exec you are out 
> of contract. If any, we may need to sanitize the input to exec, although I 
> don't think is worth paying the performance price for that.

exec() params are already checked, as a seconds param, only dict or dict 
subclasses are accepted. Seems like good enough contract.

> Paul, I don't know if you are being sarcastic here so I will assume that you 
> are not but in case you are, I suggest you stop as this violates our CoC.

I am not, and please stop your accusations, that violates CoC.

--

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

[issue32615] Inconsistent behavior if globals is a dict subclass



Paul Sokolovsky  added the comment:

> The doc for exec says globals "must be a dictionary (and not a subclass of 
> dictionary)"

Docs are full of mistakes and outdated information.

Fixing STORE_GLOBAL case from https://bugs.python.org/issue36220#msg359046 
would be trivial and cheap re: overheads. And useful, yeah.

And the gentleman who submitted the other ticket argues that:

> but the inconsistency between LOAD_NAME and LOAD_GLOBAL definitely seems 
> wrong.

Which is easy to agree with, though there're more concerns re: runtime overhead.

--

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

[issue32615] Inconsistent behavior if globals is a dict subclass



Paul Sokolovsky  added the comment:

Some smart maintainer closed https://bugs.python.org/issue36220 as a duplicate 
of this one. That ticket might have more details of the underlying issues.

--
nosy: +pfalcon

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

[issue39167] argparse boolean type bug

2019-12-30 Thread paul j3



paul j3  added the comment:

The rejected boolean type proposal:

https://bugs.python.org/issue37564

--

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

[issue39167] argparse boolean type bug

2019-12-30 Thread paul j3



paul j3  added the comment:

Despite the name, the 'type' parameter specifies a function, not a Python 
class.  

The only string that produces False is the empty one: bool('').  So 'type=bool' 
is valid Python, even if it isn't useful.

With `nargs='+'` there's no problem with providing strings like 'False', 
'true', 'no', 'oui', 'niet', but if you want to convert those to boolean 
True/False values, you need to write your own 'type' function.


There was a recent bug/issue that proposed providing such a function (or 
importing it from another module), and shadowing the existing 'bool' function, 
but that has been rejected (I think).  It isn't really needed, and the proposed 
solution was too language specific.

Seems to me that expecting your user to provide an open ended list of 'True 
False False True' strings would be rather confusing, or at least require a 
complicated 'help' string.  In any case it's not a common enough case to 
require any changes to the core argparse functionality.

In sum, it isn't clear what the bug is, or what patch you expect.  This sounds 
more like a StackOverflow question, than a bug report.

--

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

[issue36220] LOAD_NAME and LOAD_GLOBAL, STORE_GLOBAL handle dict subclasses for globals() differently



Paul Sokolovsky  added the comment:

> I wanted to write a sandbox for Python.

Sandbox indeed, it is.

class NS(dict):

def __setitem__(self, k, v):
if not isinstance(v, type(lambda: 0)):
raise RuntimeError("Global variables considered harmful")

globals = NS()

exec("foo = 1", globals)

But then:

exec("""
global foo
foo = "watch me escaping your sandboxes"
""", globals)

This is due to STORE_GLOBAL not handling dict subclasses, unlike STORE_NAME.


While @Kevin Shweh's issue with LOAD_NAME, and @vstinner's concerns of adding 
yet another branch to LOAD_NAME implementation may be one matter, issue with 
STORE_GLOBAL is both related and somewhat different. STORE_GLOBAL's should be 
relatively infrequent, so adding another branch to it unlikely will be 
quantifiable in performance. But lack of its support disallows to write to 
tools which police/constrain Python's overdynamicity, which is useful in the 
age.

Anyway, I decided to not open a separate ticket for this, but add here. Fairly 
speaking, as long as work to support dict subclasses as globals/locals started, 
the only reasonable way forward seems to implement it completely.

--

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

[issue36220] LOAD_NAME and LOAD_GLOBAL, STORE_GLOBAL handle dict subclasses for globals() differently



Change by Paul Sokolovsky :


--
nosy: +pfalcon
title: LOAD_NAME and LOAD_GLOBAL handle dict subclasses for globals() 
differently -> LOAD_NAME and LOAD_GLOBAL, STORE_GLOBAL handle dict subclasses 
for globals() differently

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

[issue13305] datetime.strftime("%Y") not consistent for years < 1000

2019-12-20 Thread Paul Ganssle



Change by Paul Ganssle :


--
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.6

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

[issue39103] [linux] strftime renders %Y with only 3 characters

2019-12-20 Thread Paul Ganssle



Paul Ganssle  added the comment:

This is a duplicate of issue 13305.

Right now we have some shims around `strftime` to improve consistency in some 
situations and for other reasons, but mostly we just call the libc version.

There is an open issue from 2008 (#3173) to ship our own implementation of 
strftime that could smooth out some of these issues and try and make the 
behavior more consistent (though presumably some people have started to rely on 
platform-specific behaviors by now, so it may be a decent amount of work to 
roll it out).

I'm going to close this in favor of 13305, but thanks for reporting it!

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> datetime.strftime("%Y") not consistent for years < 1000
type:  -> behavior

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

[issue39058] argparse should preserve argument ordering in Namespace

2019-12-17 Thread paul j3



paul j3  added the comment:

This patch changes the super class, _AttributeHolder.  ArgumentParser and 
Actions also inherit from this, though they have their own _get_kwargs methods, 
and so aren't affected by the sort and its removal.

I just had occasion on stackoverflow to discuss the order in which attributes 
are added.  A poster wanted to preserve the sys.argv order.

https://stackoverflow.com/questions/58904423/find-the-order-of-arguments-in-argparse-python3/58905067#58905067

Most attributes are added as defaults at the start of parsing - via a loop 
through parser._actions.  Predefining the namespace, SUPPRESS defaults, 
parser.set_defaults may alter this default order.

Anyways removing the sort makes sense, and the proposed change phrase "in the 
order attributes were added" is sufficiently general.

--
nosy: +paul.j3

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

[issue39076] Use types.SimpleNamespace for argparse.Namespace

2019-12-17 Thread paul j3



Change by paul j3 :


--
nosy: +paul.j3

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

[issue39051] Python not working on Windows 10

2019-12-15 Thread Paul Moore



Paul Moore  added the comment:

Can you also confirm that the installation of Python was done with the standard 
Python installer from the python.org website, and is not another distribution 
(such as Anaconda)?

--

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

[issue39051] Python not working on Windows 10

2019-12-15 Thread Paul Moore



Paul Moore  added the comment:

> sys.path = [
>'C:\\Developing\\Python\\python38.zip',
>'C:\\Developing\\Python\\python-3.8.0.amd64\\Lib\\',
>'C:\\Developing\\Python\\python-3.8.0.amd64\\Lib\\lib-tk',
>'C:\\Developing\\Python\\python-3.8.0.amd64\\DLLs\\',
>'C:\\Developing\\Python',

The subdirectory python-3.8.0.amd64 in the various paths above should not be 
present, and would not be in a normal clean Python installation. It appears 
that somehow your installation has been corrupted.

I would recommend a clean install. if that doesn't work, it's likely that some 
environment variables or registry paths in your system are set incorrectly (or 
at least, in ways the standard installation is not expecting).

--

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

[issue39025] Windows Python Launcher does not update PATH to Scripts directory

2019-12-11 Thread Paul Moore



Paul Moore  added the comment:

Most items in the Scripts directory can be run using the `-m` flag to Python, 
so you can use something like `py -m pip` to run pip without needing the 
Scripts directory in PATH.

If an individual project like PyQt doesn't support -m, it's relatively easy for 
them to add, so it might be worth suggesting to them.

--

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

[issue38999] Python launcher on Windows does not detect active venv

2019-12-09 Thread Paul Moore



Paul Moore  added the comment:

See PEP 486 (https://www.python.org/dev/peps/pep-0486/). This is intended 
behaviour, as it is assumed that explicitly specifying a Python version means 
that the user had a specific Python interpreter in mind.

There are also technical issues - if the shebang says #!/usr/bin/python2, and a 
virtual environment is active, how do we know if it's a Python 2 or 3 
environment (without launching the interpreter, which is a significant extra 
cost for the launcher)? It would definitely be wrong to launch a Python 3 
interpreter in that case.

--

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

[issue38999] Python launcher on Windows does not detect active venv

2019-12-09 Thread Paul Moore



Change by Paul Moore :


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

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

[issue38999] Python launcher on Windows does not detect active venv

2019-12-09 Thread Paul Moore



Paul Moore  added the comment:

See PEP 486 
(https://www.youtube.com/watch?v=Lmq13nrEFaM=PLuE3ABw6vYeR0gcPT6uj25ZZhmSP9vRB2=28=0s).
 This is intended behaviour, as it is assumed that explicitly specifying a 
Python version means that the user had a specific Python interpreter in mind.

There are also technical issues - if the shebang says #!/usr/bin/python2, and a 
virtual environment is active, how do we know if it's a Python 2 or 3 
environment (without launching the interpreter, which is a significant extra 
cost for the launcher)? It would definitely be wrong to launch a Python 3 
interpreter in that case.

--

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

[issue38974] using filedialog.askopenfilename() freezes python 3.8

2019-12-04 Thread Paul Moore



Change by Paul Moore :


--
nosy: +gpolo, serhiy.storchaka

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

[issue38974] using filedialog.askopenfilename() freezes python 3.8

2019-12-04 Thread Paul Moore



Paul Moore  added the comment:

Can you provide a minimal, self-contained, example of a program that 
demonstrates this behaviour in 3.8, but works in 3.7. It's not really possible 
to determine what the issue might be without a means of reproducing the problem.

--
components: +Tkinter -Windows

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

[issue38950] argparse uses "optional arguments" for "keyword arguments"

2019-12-02 Thread paul j3



paul j3  added the comment:

This related to an old issue

https://bugs.python.org/issue9694
argparse required arguments displayed under "optional arguments"

argparse defines two initial argument groups, titled 'positional arguments' and 
'optional arguments'.   Alternatives have been suggested, such as 'flagged 
arguments' and/or 'required arguments'.  But nothing was settled.

Users can define their own argument groups. 

I'd suggest closing this a duplicate, though we can certainly revisit the 
earlier discussion.

--
nosy: +paul.j3

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

[issue38021] pep425 tag for AIX is inadequate

2019-11-26 Thread Paul Moore



Paul Moore  added the comment:

> replacement platform_tag, not compatibility tag.

Ah, I see, sorry. In that case, this should be fine, it's purely a CPython 
question. There's obviously a follow-on discussion about how that platform tag 
is *incorporated* into the compatibility tags, but as you say, that's a 
separate point.

--

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

[issue38914] Clarify wording for warning message when checking a package

2019-11-26 Thread Paul Ganssle



Paul Ganssle  added the comment:

For the future, we generally tend to keep distutils pretty "frozen", only 
making minor changes or the changes needed to build Python itself. Instead we 
generally make changes in setuptools, which for the moment monkey-patches 
distutils (and into which distutils will eventually be merged). One of the big 
reasons is that setuptools is used across all versions of Python, so the 
changes are automatically backported, whereas changes to distutils will only be 
seen by people using the most recent Python versions.

In this case, it's not really a substantive change, so I think we can leave it 
in distutils, I just wanted to bring this up as an FYI.

--
nosy: +p-ganssle

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

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

2019-11-25 Thread Paul Moore



Paul Moore  added the comment:

I presume there's also the option of setting up the environment (or however 
it's done now - I know the details changed as the feature was developed) so 
that the "base" python.exe pretends to be the venv one, exactly as the wrapper 
does.

However, that may well have other difficult-to-fix implications, not least that 
calling the base Python using an explicit full path should act like the base 
Python, and *not* like the venv one.

IMO, the key thing here is that either the various limitations/quirks of 
redirecting to the base Python should either be treated as bugs, or they should 
be documented (even if only in the form of explicitly saying not to rely on any 
specific behaviour - e.g. "running an unqualified python and expecting a PATH 
search to pick up the same executable as the parent shell would is not 
supported and may produce unexpected results").

Virtual environments are a key part of most Python development workflows, and 
virtualenv is in the process of switching to use the core venv module 
internally. When that happens, there will be a lot more visibility for 
unexpected behaviours like this one.

--

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

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

2019-11-25 Thread Paul Moore



Paul Moore  added the comment:

Yes, it does.

I think we'd need input from Steve Dower here, as these changes were made (I 
believe) in support of the Windows Store build of Python, so any changes would 
need to be considered in the light of how they would affect that. I do, 
however, consider this to be a regression that should be fixed.

BTW, just for completeness,

>>> subprocess.check_output([sys.executable, '-c', 'import sys; 
>>> print(sys.executable)'])

works as I'd expect, and that's the idiom that is often used. So relying on a 
path search to find the correct Python can be considered an unusual case (but 
nevertheless one I'd expect to be fixed).

I assume that the issue here is that the code is being run by the python.dll in 
the base environment, and whens searching for executables, Windows gives "exes 
that are in the same directory as the currently executing code" priority over 
PATH. See 
https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw,
 specifically

"""
If the file name does not contain a directory path, the system searches for the 
executable file in the following sequence:

1. The directory from which the application loaded.
2. The current directory for the parent process.
3. The 32-bit Windows system directory. Use the GetSystemDirectory function to 
get the path of this directory.
4. The 16-bit Windows system directory. There is no function that obtains the 
path of this directory, but it is searched. The name of this directory is 
System.
5. The Windows directory. Use the GetWindowsDirectory function to get the path 
of this directory.
6. The directories that are listed in the PATH environment variable. Note that 
this function does not search the per-application path specified by the App 
Paths registry key. To include this per-application path in the search 
sequence, use the ShellExecute function.
"""

--

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

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

2019-11-25 Thread Paul Moore



Paul Moore  added the comment:

The behaviour in this area is different between 3.7.0, 3.7.2, and 3.7.3 (at 
least). I have reproduced the issue with 3.7.3. Steve Dower made changes to the 
way the python executable works in venvs in the point releases of 3.7 - see 
https://github.com/pypa/virtualenv/issues/1380 and 
https://github.com/pypa/virtualenv/issues/1339 for some discussion of how this 
affected virtualenv.

I suspect this issue is related - from 3.7.2 onwards, the python.exe in a venv 
is a redirector which runs the "base" python.exe, but with sys.executable 
showing the redirector rather than the actual running exe.

--

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

[issue38021] pep425 tag for AIX is inadequate

2019-11-23 Thread Paul Moore



Paul Moore  added the comment:

Thanks for the clarification, Nick. Yes, I agree that the basic "this is the 
tag that matches this precise CPython installation" is not the difficult part 
of the problem here, and if that is all that this issue is targeting, there 
should be no major problem.

My understanding was that Michael wanted to address the other part of the 
issue, that installers would somehow need to encapsulate the question of what 
binaries were compatible with what installations, and that, as you say, is a 
*much* murkier question.

If you're comfortable that the two aspects can be cleanly separated (and 
ideally that the second can be avoided altogether) then I'm much happier.

--

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

[issue38021] pep425 tag for AIX is inadequate

2019-11-22 Thread Paul Moore



Paul Moore  added the comment:

What complicates the issue for AIX (and reminds me very strongly of the MacOS 
and manylinux situations, both of which were defined after the original tag 
PEP, and so contain additional insights) is the business of certain tags being 
compatible across multiple AIX versions.

That's something that needs to be fairly clearly specified, so that 
implementors and maintainers understand the design. And even more so for a 
niche platform like AIX, as we can't rely on a platform expert being available. 
(Consider for example a pip issue "this wheel says it's compatible with AIX 
x.y.z, my machine is AIX x.y.w which is documented as compatible, why isn't it 
working?")

It's possible that all of this may not have any relevance to the specific 
change to core Python, but it's hard to be sure of that when there's nothing 
other than your explanation to go on. A tagging spec would act as a clear 
reference to work from (even if it's basically just you writing up your 
knowledge, doing so would at least allow people to say "hey - I don't follow 
that bit, can you clarify").

To put it another way, you need somebody to sign off on this change as correct. 
You'll have an easier time of getting that if there's a written up spec that 
Python developers can refer to, without having to go back to (and understand) 
all of the AIX source material that it's based on.

--

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

[issue38021] pep425 tag for AIX is inadequate

2019-11-22 Thread Paul Moore



Paul Moore  added the comment:

PyPA member here - if this PR is defining new compatibility tags, I would have 
expected it to need discussion as a revision to PEP 425, much like the 
manylinux efforts did. (It may actually be a closer parallel with MacOS, which 
didn't have a tagging PEP - I'm not sure how that would relate here, but as 
MacOS is a much more mainstream platform I'd be inclined to err on the side of 
caution and look for AIX to be explicitly covered in the tag specs).

I thought that was something that had been discussed on the Pip tracker, but 
maybe the implications weren't clear (I don't really understand the AIX scheme, 
so I'm relying on someone else, probably Michael, to propose something that 
could be added to PEP 425 and to lead/guide the discussion).

--
nosy: +paul.moore

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

[issue38843] Document argparse behaviour when custom namespace object already has the field set

2019-11-18 Thread paul j3



paul j3  added the comment:

It doesn't have to be a special class. It can be a `argparse.Namespace` object. 
 If the preexisting namespace has an attribute set, the action default will not 
over write it.

In [85]: parser = argparse.ArgumentParser() 
...: parser.add_argument('--foo', default='bar') 
...: parser.parse_args([],
 namespace=argparse.Namespace(foo=123, baz=132))   
Out[85]: Namespace(baz=132, foo=123)

This is described in comments at the start of parse_known_args()


# add any action defaults that aren't present
for action in self._actions:
if action.dest is not SUPPRESS:
if not hasattr(namespace, action.dest):
if action.default is not SUPPRESS:
setattr(namespace, action.dest, action.default)

# add any parser defaults that aren't present
for dest in self._defaults:
if not hasattr(namespace, dest):
setattr(namespace, dest, self._defaults[dest])

There are many details about 'defaults' that are not documented.  This might 
not be the most significant omission.  

I have not seen many questions about the use of a preexisting namespace object 
(here or on StackOverflow).  While such a namespace can be used to set custom 
defaults (as shown here), I think it is more useful when using a custom 
Namespace class, one the defines special behavior.

Originally the main parser's namespace was passed to subparsers.  But a change 
in 2014, gave the subparser a fresh namespace, and then copied values from it 
back to the main namespace.  While that gave more power to the subparser's 
defaults, users lost some ability to use their own namespace class.

https://bugs.python.org/issue27859 - argparse - subparsers does not retain 
namespace

https://bugs.python.org/issue9351 - argparse set_defaults on subcommands should 
override top level set_defaults

https://bugs.python.org/issue34827 - Make argparse.NameSpace iterable (closed)

--

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

[issue38821] argparse calls ngettext with deprecated non-integer value

2019-11-18 Thread paul j3



Change by paul j3 :


--
nosy: +paul.j3

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

[issue38812] Comparing datetime.time objects incorrect for TZ aware and unaware

2019-11-17 Thread Paul Ganssle



Paul Ganssle  added the comment:

I do not think this is a bug in pytz, but if it's a bug in Python it's one in 
reporting what the error is.

The issue is that the time zone offset for "rules-based zones" like 
America/Denver (i.e. most time zones) is *undefined* for bare times, because 
the offset that apply depends on the *date* and the *time*.

The documentation for `tzinfo.utcoffset` specifies that if the offset is 
unknown, a time zone offset should return None: 
https://docs.python.org/3/library/datetime.html#datetime.tzinfo.utcoffset

The documentation for determining whether an object is aware or naive also 
specifies that if utcoffset() returns `None`, the object is naive (even if 
tzinfo is not None): 
https://docs.python.org/3/library/datetime.html#determining-if-an-object-is-aware-or-naive

So basically, everyone is doing the right thing except the person who attached 
this `pytz` time zone to a time object (as a side note, it may be worth reading 
this blog post that explains why the way this time zone is attached to the 
`time` object is incorrect: 
https://blog.ganssle.io/articles/2018/03/pytz-fastest-footgun.html).

That said, we may be able to improve the error message raised here by 
distinguishing between the case where there's no `tzinfo` at all and the case 
where `utcoffset()` returns `None`. I think we can change the exception message 
to have a helpful hint like, "cannot compare offset-naive and offset-aware 
times; one of the operands is offset-naive because its offset is undefined."

We could possibly be even more specific.

--
components: +Library (Lib)
versions: +Python 3.9 -Python 3.6

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

[issue38736] argparse: wrong type from get_default when type is set

2019-11-12 Thread paul j3



Change by paul j3 :


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

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

[issue38736] argparse: wrong type from get_default when type is set

2019-11-08 Thread paul j3



paul j3  added the comment:

Yes you can set the default to be any object, such as an evaluated string.  If 
it isn't a string it won't be passed through 'type'.

The purpose of the delayed evaluation that I described is to avoid unnecessary 
evaluations.  The worse case would be a write filetype.  You don't want to 
create (or over write) a default file if it never gets used.

(I intend to close this issue).

--

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

[issue38736] argparse: wrong type from get_default when type is set

2019-11-07 Thread paul j3



paul j3  added the comment:

get_default just returns the default attribute as it is stored in the Action.   
Defaults are stored as given. 

During parsing the Action's default is placed in the args namespace at the 
start.  At the end, it checks if the value in the namespace is a string that 
matches the default (i.e. has been over written by user input).  Only then is 
it passed through the type function.

--
nosy: +paul.j3

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

[issue38734] Python 3.7 and 3.8 in Windows Store do not start under git bash

2019-11-07 Thread Paul Anton Letnes



New submission from Paul Anton Letnes :

Python 3.7 and 3.8 installed from the  Windows Store do not start under git 
bash. Rather, they give some variation of this error message:

bash: /c/Users/pa/AppData/Local/Microsoft/WindowsApps/python: Permission denied

However, the permissions are rwxr-xr-x, or 755 if you prefer. The same error 
occurs if I try to run pip.

How can I run python under git bash? I use python and various pip-installed 
executables (e.g. black) for git hooks, so this has to work for my workflow.

--
components: Windows
messages: 356183
nosy: paul.moore, pletnes, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python 3.7 and 3.8 in Windows Store do not start under git bash
type: crash
versions: Python 3.7, Python 3.8

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

[issue38590] argparse unexpected behavior with argument group inside mutually exclusive group

2019-11-04 Thread paul j3



paul j3  added the comment:

With one exception, groups are not designed or intended to be nested.  But by 
inheritance (from _ActionsContainer) nesting isn't blocked nor does it raise 
any errors.

As you surmise, an ArgumentGroup, is used only for grouping the help lines.  By 
default that are two groups, with 'optionals' and 'required' names (actually 
the later should be 'positional').  The rest are user defined.  They don't 
affect parsing in any way.

MutuallyExclusiveGroup is used in parsing.  It also is used, to the extent 
possible, when formatting usage.

If a MutuallyExclusiveGroup is nested inside another MutuallyExclusiveGroup the 
parsing effect is just one flat group.  Usage can be messed up - that's been 
the subject of another bug/issue.

A MutuallyExclusiveGroup may be put in an ArgumentGroup.  This is a way of 
giving the exclusive group a title and/or description in the help.

There is a bug/issue requesting some sort of inclusive group.  I tried to 
develop such a patch, implementing nesting, complete logic control (not just 
the current xor).  But the usage formatting needs a complete rewrite.  Overall 
this is too complex of an addition.  On StackOverFlow I tell people to 
implement their own post-parsing testing.

--
nosy: +paul.j3

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

[issue11354] argparse: nargs could accept range of options count

2019-11-03 Thread paul j3



paul j3  added the comment:

A couple of quick observations:

- this is one of the first patches that I worked on, so the details aren't 
fresh in my mind.  A glance at my latest patch show that this isn't a trivial 
change.  

- nargs changes affect the input handling, the parsing, help and usage 
formatting, and error formatting.  As a result, nargs are referenced in several 
places in the code.  That complicates maintenance and the addition of new 
features.  Help formatting is particularly brittle; just look at the number of 
issues that deal with 'metavar' to get a sense of that.

- At one point I tried to refactor the code to consolidate the nargs handling 
in a few functions.  I don't recall if I posted that as a patch.

- The first posts on this topic suggested a (n,m) notation; I proposed a regex 
like {n,m}.  There wasn't any further discussion.

- Note that the initial posts were in 2011 when Steven (the original author) 
was involved.  I posted in 2013.  There hasn't been any further action until 
now.  I don't recall much interest in this topic on Stackoverflow either.  So 
my sense is that this isn't a pressing issue.

- It's easy to test for this range after parsing, with '*' or '+' nargs.  So 
the main thing this patch adds is in the help/usage display.  It doesn't add 
significant functionality.

- cross links:

https://bugs.python.org/issue9849 - Argparse needs better error handling for 
nargs

https://bugs.python.org/issue16468 - argparse only supports iterable choices 
(recently closed)

--
nosy: +rhettinger

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

[issue37903] IDLE Shell sidebar.

2019-11-02 Thread Stephen Paul Chappell



Stephen Paul Chappell  added the comment:

@rhettinger: The turtle demo is easily accessible through the menus via Help > 
Turtle Demo.

It is nice to see there are others interested in IDLE's improvement. :-)

--

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

[issue37527] Timestamp conversion on windows fails with timestamps close to EPOCH



Paul Ganssle  added the comment:

Ah, my mistake. The examples all use `datetime.fromtimestamp`, so I didn't 
notice that it was failing only on the `timestamp` side. Re-opening, thanks!

--
resolution: duplicate -> 
status: closed -> open
superseder: [Windows] datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on 
Python 3.6 -> 

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

[issue36439] Inconsistencies with datetime.fromtimestamp(t) when t < 0



Paul Ganssle  added the comment:

This has been coming up in a few different contexts lately, so I think it would 
be really good if we could get some sort of fix for it.

One option is to implement our own versions of these APIs for use in Windows, 
but a thought occurred to me recently: we have not investigated the possibility 
of seeing if Microsoft would be willing to either add support for negative 
timestamps in their localtime() or gmtime() implementations or add a new API 
that *does* support negative timestamps. It would also be good to rule out the 
possibility that such APIs already exist but we just don't know about them 
(preliminary googling doesn't show anything, though possibly something can be 
done with the Win32 APIs? Not sure how or if those work in C and how big a lift 
it would be to maintain compatibility if can switch: 
https://docs.microsoft.com/en-us/windows/win32/sysinfo/time-functions?redirectedfrom=MSDN
 ).

Adding Steve Dower to the nosy list in case he can shed some light onto the 
possibility of native support.

--
nosy: +steve.dower

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

[issue38233] datetime.datetime.fromtimestamp have different behaviour on windows and mac



Paul Ganssle  added the comment:

Changing the superceder here as I think #36439 matches better than #37527.

--
nosy: +p-ganssle
resolution: duplicate -> 
status: closed -> open
superseder: Timestamp conversion on windows fails with timestamps close to 
EPOCH -> Inconsistencies with datetime.fromtimestamp(t) when t < 0

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

[issue37527] Timestamp conversion on windows fails with timestamps close to EPOCH



Paul Ganssle  added the comment:

This indeed seems to be a duplicate of 29097, which is fixed in Python 3.7, so 
we can close this bug. Thank you for your report Dschoni, and thank you for 
finding the duplicate Ma Lin!

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> [Windows] datetime.fromtimestamp(t) when 0 <= t <= 86399 fails 
on Python 3.6

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

[issue37903] IDLE Shell sidebar.

2019-11-01 Thread Stephen Paul Chappell



Stephen Paul Chappell  added the comment:

Zero: "not to have them added as text as is usual in a terminal window"
taleinat: "removing prompts from the shell window's text widget"

Zero: "print the values of ps1 and ps2 in the proposed ShellIO subclass"
taleinat: "separate sidebar showing where prompts and user input were"

We appear to be in agreement.

terry.reedy: "Labels, such as '>>>', 'Out', 'Inp', and 'Err' would be used"
Zero:"Having IDLE react to sys.ps1 and sys.ps2"

My suggestion is to take those labels terry.reedy talks about from the values 
of ps1 and ps2 since they are already documented and standard for "the 
interpreter ... in interactive mode." If psX needs to introduced for other 
prompts that may be needed ("Maybe use 'Con', maybe use Dbg and Wrn."), it 
would provide a sensible way to customize those labels as well.

--

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

[issue32309] Implement asyncio.run_in_executor shortcut

2019-11-01 Thread Paul Martin



Paul Martin  added the comment:

Good points. I made a mistake in run

Should be:

async def run(self, func, *args, **kwargs):
call = functools.partial(func, *args, **kwargs)
return await self._loop.run_in_executor(self._executor, call)

Also in this case run awaits and returns the result. Yury suggested earlier 
just to return the future and not await. I have no strong opinion either way. 
The above example does seem more higher level but Yury's example is more 
flexible.

I agree that shutdown_default_executor and _do_shutdown should be changed to 
accept an executor argument so that any executor can be shutdown 
asynchronously. So the loop API would have a shutdown_executor method. 
shutdown_default_executor would just call shutdown_executor with the default 
executor as argument. That would be a good first step.

--

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

[issue32309] Implement asyncio.run_in_executor shortcut

2019-11-01 Thread Paul Martin



Paul Martin  added the comment:

Run method should be:

async def run(self, func, *args, **kwargs):
call = functools.partial(func, *args, **kwargs)
return await self._loop.run_in_executor(None, call)

--

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

[issue32309] Implement asyncio.run_in_executor shortcut

2019-11-01 Thread Paul Martin



Paul Martin  added the comment:

I don't think changing the default executor is a good approach. What happens, 
if two or more thread pools are running at the same time? In that case they 
will use the same default executor anyway, so creating a new executor each time 
seems like a waste. 

Shutting down the default executor seems unnecessary and could impact lower 
level code which is using it. The default executor is shutdown at the end of 
asyncio.run anyway.

I also think it would be good to have a synchronous entry point, and not 
require a context manager. Having a ThreadPool per class instance would be a 
common pattern.


class ThreadPool:
def __init__(self, timeout=None):
self.timeout = timeout
self._loop = asyncio.get_event_loop()
self._executor = concurrent.futures.ThreadPoolExecutor()

async def close(self): 
await self._executor.shutdown(timeout=self.timeout)  

async def __aenter__(self):
return self

async def __aexit__(self, *args):
await self.close()

def run(self, func, *args, **kwargs):
call = functools.partial(func, *args, **kwargs)
return self._loop.run_in_executor(self._executor, call)


I'm not sure if a new ThreadPoolExecutor really needs to be created for each 
ThreadPool though.

--
nosy: +primal

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

[issue36664] argparse: parser aliases in subparsers stores alias in dest variable

2019-10-31 Thread paul j3



paul j3  added the comment:

Just clarify how the code currently works.  `subparsers` is a positional Action 
of subclass _SubParsersAction.  It has a nargs='+...', requiring at least one 
string, and taking all remaining strings.  Its __call__ has the standard 
signature.  So everything that's special about subparsers is embodied in this 
Action subclass.  

def __call__(self, parser, namespace, values, option_string=None):
parser_name = values[0]
arg_strings = values[1:]

# set the parser name if requested
if self.dest is not SUPPRESS:
setattr(namespace, self.dest, parser_name)

# select the parser
try:
parser = self._name_parser_map[parser_name]
...

So the `parser_name` is first string, the actual alias that user provided.  It 
is added to the namespace if a `dest` was provided (the default `dest` is 
SUPPRESS).  That's all of the relevant code - the alias is simply added to to 
Namespace.

As mentioned before `parser_name` is used find the actual sub parser, which is 
called with the remaining `arg_strings`.

Earlier in the subclasses `add_parser` method, the 'name' and 'alias' list are 
used to populate the '_name_parser_map' mapping, and also create the metavar 
that's used in the help display.  But neither is saved as an attribute.

---

I still think 'set_defaults' is the cleanest way of saving a unique name for a 
sub parser.

parser_foo.set_defaults(func=foo, name='foo')

---

One further note - if you make subparsers required, you should also set a dest 
name:

parser.add_subparsers(dest='cmd', required=True)

otherwise the missing-subparsers error message will raise an error.  It needs 
to identify the missing action in some way.  Functionally, this might be the 
most important reason to set the 'dest'.

--

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

[issue37903] IDLE Shell sidebar.



Stephen Paul Chappell  added the comment:

Maybe my impression has been false this whole time, but the Python interactive 
interpreter seems to be very similar to the IDLE shell window. My question is, 
"Why not make them even more so?" Having IDLE react to sys.ps1 and sys.ps2 
opens up the shell to similar use cases as having them defined in the 
interactive interpreter. My suggestion is not to have them added as text as is 
usual in a terminal window but to print the values of ps1 and ps2 in the 
proposed ShellIO subclass. That would make label customization possible in a 
way that is already documented and standard.

--

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

[issue6188] Error Evaluating float(x) ** float(y)



Change by Stephen Paul Chappell :


--
nosy:  -Zero

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

[issue21957] ASCII Formfeed (FF) & ASCII Vertical Tab (VT) Have Hexadecimal Representation



Change by Stephen Paul Chappell :


--
nosy:  -Zero

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

[issue24185] Add Function for Sending File to Trash (or Recycling Bin)



Change by Stephen Paul Chappell :


--
nosy:  -Zero

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

[issue21402] tkinter.ttk._val_or_dict assumes tkinter._default_root exists



Change by Stephen Paul Chappell :


--
nosy:  -Zero

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

[issue18601] Example "command-line interface to difflib" has typographical error



Change by Stephen Paul Chappell :


--
nosy:  -Zero

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

[issue21537] functools.lru_cache does not cache exceptions



Change by Stephen Paul Chappell :


--
nosy:  -Zero

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

[issue18558] Iterable glossary entry needs clarification



Change by Stephen Paul Chappell :


--
nosy:  -Zero

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

[issue31848] "aifc" module does not always initialize "Aifc_read._ssnd_chunk"



Change by Stephen Paul Chappell :


--
nosy:  -Zero

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

[issue31476] Stdlib source files not installed



Change by Stephen Paul Chappell :


--
nosy:  -Zero

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

[issue7676] IDLE shell shouldn't use TABs



Change by Stephen Paul Chappell :


--
nosy:  -Zero

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

[issue37903] IDLE Shell sidebar.