Re: ModuleNotFoundError: No module named 'Paramiko'
Thomas Passin writes:
> On 4/8/2024 2:01 PM, Dietmar Schwertberger via Python-list wrote:
>> To be sure, you can always go the the directory of the Python
>> interpreter and open a cmd window there.
>> (By entering 'cmd' into the explorer address bar.)
>> Then enter 'python.exe -mpip install paramiko'.
>> This way you can be sure that you're not running a pip.exe that
>> belongs to another Python interpreter.
>
> This is not quite right. The best name of the Python executable may or
> may not be "python.exe". The command line needs a space after the
> "-m":
No, the option and its argument can be bundled. "-mpip" is equivalent
to "-m pip". (The space might make it clearer for human readers.)
[...]
--
Keith Thompson (The_Other_Keith) keith.s.thompso...@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
--
https://mail.python.org/mailman/listinfo/python-list
Re: Invalid literal for int() with base 10?
Keith Thompson writes:
> "Kevin M. Wilson" writes:
>> Ok, I'm not finding any info. on the int() for converting a str to an
>> int (that specifies a base parameter)?!
>
> https://docs.python.org/3/library/functions.html#int
[...]
Or `print(int.__doc__)` at a Python ">>>" prompt, or `pydoc int`
(or `pydoc3 int`) at a shell prompt. The latter may or may not be
available.
--
Keith Thompson (The_Other_Keith) keith.s.thompso...@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
--
https://mail.python.org/mailman/listinfo/python-list
Re: Invalid literal for int() with base 10?
"Kevin M. Wilson" writes:
> Ok, I'm not finding any info. on the int() for converting a str to an
> int (that specifies a base parameter)?!
https://docs.python.org/3/library/functions.html#int
> The picture is of the code I've written...
I don't see a picture. The mailing list probably does not accept
attachments. (You don't need a picture anyway.)
> And the base 10 paradigm involved??
The int() constructor takes a base parameter whose default value is 10.
If you specify base=0, it will accept binary, octal, and hexadecimal
numbers in addition to decimal. All this is explained in the link I
gave you.
> years = int('y') # store for calculationValueError: invalid
> literal for int() with base 10: 'y'What is meant by "invalid literal"?
'42' is a valid literal for int(). 'y' is not.
What value did you expect int('y') to give you?
Perhaps you have a variable named 'y' containing a string? If so, you
might want something like int(y) or int(f{'y'}), but int('y') passes the
literal string 'y', which has nothing to do with a variable of that
name.
> I'm trying to convert srt to int,
Do you mean "str to int"?
> and I didn't know I needed to specify the base.
You don't. If you don't specify the base, it defaults to 10.
> Plus I haven't read anything that I need to specify
> the base for the int(). Attached is the code, showing the code and
> the execution of said code.
Any attachment was removed.
> "When you pass through the waters, I will
> be with you: and when you pass through the rivers, they will not sweep
> over you. When you walk through the fire, you will not be burned: the
> flames will not set you ablaze." Isaiah 43:2
You can add a signature to all your messages if you like, but it will be
very helpful if you introduce it with a line consisting of "-- ", as
I've done here.
It would also be very helpful if you introduce line breaks into your
message, particularly before and after any included code. The
formatting made your message difficult to read.
--
Keith Thompson (The_Other_Keith) keith.s.thompso...@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
--
https://mail.python.org/mailman/listinfo/python-list
Re: What to use instead of nntplib?
Grant Edwards writes:
> On 2023-05-21, Retrograde wrote:
>> Who ever came up with "Removing dead batteries" as a slogan, when
>> some of those batteries still work perfectly well, needs to rethink
>> it. Go ahead and remove code that no longer works, OK. But removing
>> unpopular modules? That undercuts the entire philosophy of the
>> platform, in my opinion.
>
> And one of the metrics of "popularity" seems to be "activity"
> (e.g. changes committed). For things that have been around for 20+
> years and have all the features they need and all of the bugs fixed
> (and are now very stable) that lack of "activity" is interpreted as
> "unpopular" regardless of how many people are using the module.
My understanding is that nntplib isn't being erased from reality,
it's merely being removed from the set of modules that are provided
by default.
I presume that once it's removed from the core, it will still be
possible to install it via pip or some other mechanism.
You can disable the deprecation warning:
import warnings
warnings.filterwarnings("ignore", category=DeprecationWarning)
import nntplib
If my understanding is correct, why is this such a big problem?
--
Keith Thompson (The_Other_Keith) keith.s.thompso...@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
--
https://mail.python.org/mailman/listinfo/python-list
Re: What do these '=?utf-8?' sequences mean in python?
Chris Green writes:
> Chris Green wrote:
>> I'm having a real hard time trying to do anything to a string (?)
>> returned by mailbox.MaildirMessage.get().
>>
> What a twit I am :-)
>
> Strings are immutable, I have to do:-
>
> newstring = oldstring.replace("_", " ")
>
> Job done!
Not necessarily.
The subject in the original article was:
=?utf-8?Q?aka_Marne_=C3=A0_la_Sa=C3=B4ne_(Waterways_Continental_Europe)?=
That's some kind of MIME encoding. Just replacing underscores by spaces
won't necessarily give you anything meaningful. (What if there are
actual underscores in the original subject line?)
You should probably apply some kind of MIME-specific decoding. (I don't
have a specific suggestion for how to do that.)
--
Keith Thompson (The_Other_Keith) keith.s.thompso...@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
--
https://mail.python.org/mailman/listinfo/python-list
Re: Hide my query about covariance matrix syntax from google
Chris Angelico writes:
> On Fri, 14 Apr 2023 at 03:11, Meghna Karkera wrote:
>>
>> Respected Sir
>>
>> I kindly request you to hide my query about covariance matrix syntax from
>> google which was emailed to you a few years back as it appears on google
>> page.
>>
>> Hoping that you do the needful.
>
> These posts are public. While it's possible to ask for something to be
> removed from the official python-list archive, that won't remove it
> from Google Groups or any other third-party archive.
>
> Also, there's nothing we can do here to remove your post; you'll have
> to contact the list admins.
>
> And just in case it's of interest to you:
> https://en.wikipedia.org/wiki/Streisand_effect
It's also mirrored to Usenet (comp.lang.python). There's basically no
way to delete articles from Usenet. (The protocol includes a command to
cancel an article, but servers ignore it due to past abuse.)
--
Keith Thompson (The_Other_Keith) keith.s.thompso...@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
--
https://mail.python.org/mailman/listinfo/python-list
Re: =- and -= snag
"Morten W. Petersen" writes:
> I was working in Python today, and sat there scratching my head as the
> numbers for calculations didn't add up. It went into negative numbers,
> when that shouldn't have been possible.
>
> Turns out I had a very small typo, I had =- instead of -=.
>
> Isn't it unpythonic to be able to make a mistake like that?
Very early versions of C (around 1975 or so, before K was
published) actually used "op=" for compound assignment operators, so
`x =- 2` would subtract 2 from x. It was changed to "=op" (`x -= 2`)
precisely to avoid this ambiguity that programmers kept running
into (people were less generous with whitespace back then).
As late as the late 1990s, I used a compiler (VAXC) that still
recognized the old-style compound assignment operators, though I
think it warned about them.
I thought "Pythonic" was more about how you write code than about the
design of the language. But designing a language syntax so typos are
likely to be syntax errors rather than valid code with different
semantics is an interesting challenge.
--
Keith Thompson (The_Other_Keith) keith.s.thompso...@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.10 Fizzbuzz
Greg Ewing writes:
> On 2/03/23 10:59 am, gene heskett wrote:
>> Human skin always has the same color
>
> Um... no?
You took that out of context. The assertion was that "Human skin
always has the same color" and "the difference is not the color,
but the brightness". I offer no opinion on whether that's accurate.
--
Keith Thompson (The_Other_Keith) keith.s.thompso...@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
--
https://mail.python.org/mailman/listinfo/python-list
Re: hello can I be in your group?
September Skeen writes:
> I was wondering if I could be in your group
This is an unmoderated Usenet newsgroup. It doesn't have members, just
people who post to it. If you want to discuss Python, just post. (Take
a look around first to get an idea how how thinks work.)
If you see a response from "Manosh Manosh", I recommend ignoring it.
He appears to be a spammer.
--
Keith Thompson (The_Other_Keith) keith.s.thompso...@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
--
https://mail.python.org/mailman/listinfo/python-list
Re: What should go to stdout/stderr and why Python logging write everything to stderr?
MRAB writes:
[...]
> The purpose of stderr is to display status messages, logging and error
> messages, even user prompts, and not mess up the program's actual
> output. This is important on a *nix system where you might be piping
> the output of one program into the input of another.
I would expect user prompts to be written to stdout, or perhaps to some
system-specific stream like the current tty, not to stderr. If a
program has user prompts, it probably doesn't make sense to pipe its
output to the input of another.
--
Keith Thompson (The_Other_Keith) keith.s.thompso...@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
--
https://mail.python.org/mailman/listinfo/python-list
[issue39355] The Python library will not compile with a C++2020 compiler because the code uses the reserved “module” keyword
Keith added the comment: Compile with a compiler supporting the C++20 core feature (Modules) https://en.cppreference.com/w/cpp/compiler_support In visual studio, use C/C++ > Language > CPP Language Standard > C++20 or higher On Mon, Mar 7, 2022 at 5:32 PM STINNER Victor wrote: > > STINNER Victor added the comment: > > > The Python library will not compile with a C++2020 compiler because the > code uses the reserved “module” keyword > > What is the error message? How can the error be reproduced? > > -- > > ___ > Python tracker > <https://bugs.python.org/issue39355> > ___ > -- ___ Python tracker <https://bugs.python.org/issue39355> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39355] The Python library will not compile with a C++2020 compiler because the code uses the reserved “module” keyword
Keith added the comment: the word "module" should be treated as a reserved keyword. Any use of "module" as an argument name should be changed to something else throughout the code base. On Fri, Aug 20, 2021 at 11:28 PM Hasan wrote: > > Hasan added the comment: > > We have tested with cxx-modules that issue. > module is just a specifier for export (only export is a compiler-based > keyword in >= C++20) > That's why we can use module as argument name and there's no need to > rename or delete *module arguments from header files. > > What do you recommend to do? > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1103r3.pdf > > -- > > ___ > Python tracker > <https://bugs.python.org/issue39355> > ___ > -- ___ Python tracker <https://bugs.python.org/issue39355> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44458] Duplicate symbol _BUFFER_BLOCK_SIZE when statically linking multiple modules
Change by Russell Keith-Magee : -- keywords: +patch pull_requests: +25389 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26808 ___ Python tracker <https://bugs.python.org/issue44458> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44458] Duplicate symbol _BUFFER_BLOCK_SIZE when statically linking multiple modules
New submission from Russell Keith-Magee : BPO-41486 added _BlocksOutputBuffer for the bz2, lzma and zlib module. Part of this patch included a new header file, pycore_blocks_output_buffer.h, which defines a BUFFER_BLOCK_SIZE constant. If two or more of the bz2, lzma or zlib modules are compiled as statically linked modules (i.e., added to Lib/Setup.local), this results in a duplicate symbol error when the Python executable is linked: ``` duplicate symbol '_BUFFER_BLOCK_SIZE' in: libpython3.10.a(_bz2module.o) libpython3.10.a(_lzmamodule.o) duplicate symbol '_BUFFER_BLOCK_SIZE' in: libpython3.10.a(_bz2module.o) libpython3.10.a(zlibmodule.o) ``` -- components: Extension Modules messages: 396114 nosy: freakboy3742 priority: normal severity: normal status: open title: Duplicate symbol _BUFFER_BLOCK_SIZE when statically linking multiple modules type: compile error versions: Python 3.10, Python 3.11 ___ Python tracker <https://bugs.python.org/issue44458> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25682] __package__ not set to None under pdb in Python 3
Keith Prussing added the comment: Caveat: It's been a few years so I'm trying to recall what I was doing at the time and what my original problem was. I understand and expect pdb to populate __package__ and __main__ to be what it expects when run as a module with -m. However, I believe my expectation was for it to not alter the relevant __package__ or __main__ with respect to the script being debugged. This was the behavior in Python 2.7 which changed (unexpectedly to me) in Python 3.4 (or earlier. I obviously didn't look too hard). I must have been trying to debug a script that expected to run using the -m option but could be run as a script too. A few things have changed since the original report: 1. I have forgotten which script/tool I was working on so I wouldn't be able to find it if I tried. 2. I was trying to support Python 2.7 and Python 3 (which I have 0 interest in doing ever again), 3. This small gotcha apparently hasn't tripped up anyone else. At this point, I suspect this has been overcome by events and can be closed. -- ___ Python tracker <https://bugs.python.org/issue25682> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43878] ./configure fails on Apple Silicon with coreutils uname
Keith Smiley added the comment: Someone nonchalantly updated these in https://github.com/python/cpython/commit/2fc857a5721a5b42bcb696c9cae1bbcc82a91b17 so this bug is now fixed -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue43878> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43878] ./configure fails on Apple Silicon with coreutils uname
Keith Smiley added the comment: I think given that this file seems to be updated occasionally anyways we should still land this. I agree with the sentiment that if this was a super specific fix just for this edge case maybe it wouldn't be worth it. -- ___ Python tracker <https://bugs.python.org/issue43878> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43878] ./configure fails on Apple Silicon with coreutils uname
Keith Smiley added the comment: Yep for sure, this is the first time I've hit a difference with uname specifically -- title: ./configure fails on Apple Silicon -> ./configure fails on Apple Silicon with coreutils uname ___ Python tracker <https://bugs.python.org/issue43878> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43878] ./configure fails on Apple Silicon
Keith Smiley added the comment: Thanks for checking, I was able to debug further and it turns out the actual issue is if you use `uname` from `coreutils`, you get different results: ``` % /opt/homebrew/opt/coreutils/libexec/gnubin/uname -p arm64 % /usr/bin/uname -p arm ``` I have this in my $PATH (not specifically for uname but for other coreutils binaries) which is what lead to this. This update fixes this because the newer config.sub version contains a case for `arm64` that didn't exist before https://github.com/python/cpython/pull/25450/files#diff-9c966208fd0a0c8e24a1526da6904887c378283b9b645b9740c19339884174d9R1107 So this isn't as big of an issue as I thought, but I still think it makes sense to update these files. -- ___ Python tracker <https://bugs.python.org/issue43878> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43878] ./configure fails on Apple Silicon
Keith Smiley added the comment: Thanks for taking a look. My limited understanding is also that these should be able to be updated separately from autoconf, and I feel slightly more confident knowing that in the past folks treated this update as trivial. It seems like the changes should be entirely additive, as in they support new triples but otherwise are API compatible. -- ___ Python tracker <https://bugs.python.org/issue43878> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43878] ./configure fails on Apple Silicon
Change by Keith Smiley : -- keywords: +patch pull_requests: +24179 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25450 ___ Python tracker <https://bugs.python.org/issue43878> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43878] ./configure fails on Apple Silicon
New submission from Keith Smiley : It seems that Apple Silicon support has been added in https://github.com/python/cpython/pull/22855, but when I try to build locally I see this error: ``` % ./configure checking for git... found checking build system type... Invalid configuration `arm64-apple-darwin20.3.0': machine `arm64-apple' not recognized configure: error: /bin/sh ./config.sub arm64-apple-darwin20.3.0 failed ``` I went through the `autoreconf` instructions to see if the checked in configure script was outdated, but it doesn't seem to have fixed the issue. I was able to fix this locally by updating the config.sub and config.guess files (only the former was required but I noticed in previous updates that they were updated in lockstep). I'm a bit wary about that change because it doesn't seem like they are updated frequently (they haven't been in over 3 years), but I will submit it for discussion. -- components: Build messages: 391272 nosy: keith priority: normal severity: normal status: open title: ./configure fails on Apple Silicon type: compile error versions: Python 3.10, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43878> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43220] Argparse: Explicit default required arguments with add_mutually_exclusive_group are rejected
Keith Smiley added the comment: Would someone be able to review this change? -- ___ Python tracker <https://bugs.python.org/issue43220> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42914] pprint numbers with underscore
Change by Wm. Keith van der Meulen : -- nosy: +wkeithvan nosy_count: 7.0 -> 8.0 pull_requests: +23872 pull_request: https://github.com/python/cpython/pull/25124 ___ Python tracker <https://bugs.python.org/issue42914> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43220] Explicit default required arguments with add_mutually_exclusive_group are rejected
Keith Smiley added the comment:
Here's an example outside of argparse showing this is caused by the `is`
comparison with interned string:
```
import sys
short_string = sys.argv[1]
short_default = '1'
long_string = sys.argv[2]
long_default = 'not-interned'
print(f"short comparisons: id1: {id(short_default)} id2: {id(short_string)},
eq: {short_default == short_string}, is: {short_default is short_string}")
print(f"long comparisons: id1: {id(long_default)} id2: {id(long_string)}, eq:
{long_default == long_string}, is: {long_default is long_string}")
```
```
% ./python.exe /tmp/foo.py 1 not-interned
short comparisons: id1: 4523386416 id2: 4523386416, eq: True, is: True
long comparisons: id1: 4524440064 id2: 4523395296, eq: True, is: False
```
--
___
Python tracker
<https://bugs.python.org/issue43220>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43220] Explicit default required arguments with add_mutually_exclusive_group are rejected
Change by Keith Smiley : -- keywords: +patch pull_requests: +23311 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24526 ___ Python tracker <https://bugs.python.org/issue43220> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43220] Explicit default required arguments with add_mutually_exclusive_group are rejected
New submission from Keith Smiley :
With this code:
```
import argparse
parser = argparse.ArgumentParser()
group = parser.add_mutually_exclusive_group(required=True)
group.add_argument("--foo", default="1")
group.add_argument("--bar")
args = parser.parse_args()
print(args)
```
When you explicitly pass `--foo 1`, it is treated as if no argument was passed:
```
% python3 /tmp/bug.py --foo 1
usage: bug.py [-h] (--foo FOO | --bar BAR)
bug.py: error: one of the arguments --foo --bar is required
```
I can't tell if this behavior is intentional, but it was surprising to me. It
also seems to be somewhat based on the length of the default string. For
example on my macOS machine if I change the default to `longerstring` it does
not have this issue.
--
components: Library (Lib)
messages: 386934
nosy: keith
priority: normal
severity: normal
status: open
title: Explicit default required arguments with add_mutually_exclusive_group
are rejected
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue43220>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41249] TypedDict inheritance doesn't work with get_type_hints and postponed evaluation of annotations across modules
Keith Blaha added the comment: > TBH this is not very elegant, but I think you can go ahead with this (at > least as a quick fix) since I don't see a better solution yet. Agreed, given that the current workaround of implementing them in the same module works I think I will stick with that while this is brainstormed further. -- ___ Python tracker <https://bugs.python.org/issue41249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41249] TypedDict inheritance doesn't work with get_type_hints and postponed evaluation of annotations across modules
New submission from Keith Blaha : Copied from https://github.com/python/typing/issues/737 I came across this issue while using inheritance to express required keys in a TypedDict, as is recommended by the docs. It's most easily explained by a minimal example I cooked up. Let's say we have a module foo.py: from __future__ import annotations from typing import Optional from typing_extensions import TypedDict class Foo(TypedDict): a: Optional[int] And another module bar.py: from __future__ import annotations from typing import get_type_hints from foo import Foo class Bar(Foo, total=False): b: int print(get_type_hints(Bar)) Note that both foo.py and bar.py have adopted postponed evaluation of annotations (PEP 563) by using the __future__ import. If we execute bar.py, we get the error message NameError: name 'Optional' is not defined. This is due to the combination of: get_type_hints relies on the MRO to resolve types: https://github.com/python/cpython/blob/3.7/Lib/typing.py#L970 TypedDict does not preserve the original bases, so Foo is not in the MRO for Bar: typing/typing_extensions/src_py3/typing_extensions.py Line 1652 in d79edde tp_dict = super(_TypedDictMeta, cls).__new__(cls, name, (dict,), ns) Thus, get_type_hints is unable to resolve the types for annotations that are only imported in foo.py. I ran this example using typing_extensions 3.7.4.2 (released via #709) and Python 3.7.3, but it seems like this would be an issue using the current main branches of both repositories as well. I'm wondering what the right approach is to tackling this issue. It is of course solvable by defining Bar in foo.py instead, but it isn't ideal or intuitive to always need to inherit from a TypedDict in the same module. I was thinking that similarly to __required_keys__ and __optional_keys__, the TypedDict could preserve its original bases in a new dunder attribute, and get_type_hints could work off of that instead of MRO when it is dealing with a TypedDict. I would be willing to contribute the PRs to implement this if the design is acceptable, but am open to other ideas as well. -- components: Library (Lib) messages: 373360 nosy: keithblaha priority: normal severity: normal status: open title: TypedDict inheritance doesn't work with get_type_hints and postponed evaluation of annotations across modules type: behavior versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40969] Python 3.8.3 And Now For Something CompletelyDifferent
New submission from Keith Spitz : For the totally unimportant list... On the Python 3.8.3 release page (https://www.python.org/downloads/release/python-383/), Mr. Anemone was actually played by Graham Chapman and not John Cleese (https://montypython.fandom.com/wiki/Flying_Lessons). -- assignee: docs@python components: Documentation messages: 371464 nosy: Keith Spitz, docs@python priority: normal severity: normal status: open title: Python 3.8.3 And Now For Something CompletelyDifferent versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue40969> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39930] Embedded installer for Python 3.7.7 missing vcruntime140.dll
Russell Keith-Magee added the comment: It appears the 3.7.7RC1 embedded installer was also missing the file. -- ___ Python tracker <https://bugs.python.org/issue39930> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39930] Embedded installer for Python 3.7.7 missing vcruntime140.dll
New submission from Russell Keith-Magee : The Windows python-3.7.7-embed-amd64.zip installer (released Mar 11 2020) appears to be missing vcruntime140.dll. As a result, running the python.exe or pythonw.exe included in that installer fails with a system error notifying you of the missing DLL. The 3.7.6 embedded install included this file. -- components: Build, Windows messages: 363891 nosy: freakboy3742, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Embedded installer for Python 3.7.7 missing vcruntime140.dll versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue39930> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39355] The Python library will not compile with a C++2020 compiler because the code uses the reserved “module” keyword
New submission from Keith : The Python library will not compile with a C++2020 compiler because the code uses the reserved “module” keyword For example, in warnings.h, we have the following code: #ifndef Py_LIMITED_API PyAPI_FUNC(int) PyErr_WarnExplicitObject( PyObject *category, PyObject *message, PyObject *filename, int lineno, PyObject *module, PyObject *registry); In modsupport.h we have the following code: PyAPI_FUNC(int) PyModule_ExecDef(PyObject *module, PyModuleDef *def); We can fix this by using a different identifier, for example “pyModule” instead of “module” -- components: C API messages: 360103 nosy: aCuria priority: normal severity: normal status: open title: The Python library will not compile with a C++2020 compiler because the code uses the reserved “module” keyword versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue39355> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37983] macOS: os.lchmod() incorrectly removed by 2.7.16
New submission from Keith F. Kelly : Apparently the fix for https://bugs.python.org/issue34652 was incorrect, or got incorrectly backported to, the 2.7 tree, because as of 2.7.16, the os.lchmod() built-in API is unexpectedly missing on MacOS, which is breaking our existing code. -- components: macOS messages: 350822 nosy: keithfkelly, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: macOS: os.lchmod() incorrectly removed by 2.7.16 type: behavior versions: Python 2.7 ___ Python tracker <https://bugs.python.org/issue37983> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36880] Returning None from a callback with restype py_object decrements None's refcount too much
Change by Russell Keith-Magee : -- nosy: +freakboy3742 ___ Python tracker <https://bugs.python.org/issue36880> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
3D surface plot
I should know this ...! Anyway, I have a list of 36 tuples, each with x, y, z values I want to create a surface plot ... Need help putting data into right format for matplot3D ... This is a gmail account used by Keith D. Anthony On Sat, Mar 16, 2019 at 12:03 PM wrote: > Send Python-list mailing list submissions to > python-list@python.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.python.org/mailman/listinfo/python-list > or, via email, send a message with subject or body 'help' to > python-list-requ...@python.org > > You can reach the person managing the list at > python-list-ow...@python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Python-list digest..." > Today's Topics: > >1. Re: Question regarding the local function object (Terry Reedy) >2. subprocess svn checkout password issue (Martin De Kauwe) >3. RE: asyncio Question (Joseph L. Casale) >4. Re: Implement C's Switch in Python 3 (jf...@ms4.hinet.net) >5. Re: subprocess svn checkout password issue (dieter) >6. Re: subprocess svn checkout password issue (Martin De Kauwe) >7. Re: Question regarding the local function object (Gregory Ewing) >8. Re: how to embed non-tkinter VLC player into grid of tkinter > with python? (akashsahu...@gmail.com) >9. Re: subprocess svn checkout password issue (Dan Sommers) > > > > -- Forwarded message -- > From: Terry Reedy > To: python-list@python.org > Cc: > Bcc: > Date: Fri, 15 Mar 2019 13:00:50 -0400 > Subject: Re: Question regarding the local function object > On 3/15/2019 8:47 AM, Arup Rakshit wrote: > > Hi, > > > > I am reading a book where it says that: > > > > Just like module-level function definitions, the definition of a local > function happens at run time when the def keyword is executed. > Interestingly, this means that each call to sort_by_last_letter results in > a new definition of the function last_letter. That is, just like any other > name bound in a function body, last_letter is bound separately to a new > function each time sort_by_last_letter is called. > > > > If that above is true, why the below program shows the same object > reference for last_letter every time I call function sort_by_last_letter. > > > > # file name is sample.py > > > > def sort_by_last_letter(strings): > > def last_letter(s): > > return s[-1] > > print(last_letter) > > return sorted(strings, key=last_letter) > > > > python3 -i sample.py > >>>> sort_by_last_letter(['ghi', 'def', 'abc']) > > .last_letter at 0x1051e0730> > > ['abc', 'def', 'ghi'] > >>>> sort_by_last_letter(['ghi', 'def', 'abc']) > > .last_letter at 0x1051e0730> > > ['abc', 'def', 'ghi'] > >>>> sort_by_last_letter(['ghi', 'def', 'abckl']) > > .last_letter at 0x1051e0730> > > ['def', 'ghi', 'abckl'] > > To build on Calvin's explanation ... > intersperse other function definitions between the repeated calls > > sort_by_last_letter(['ghi', 'def', 'abc']) > def a(): return 'skjsjlskjlsjljs' > print(a) > sort_by_last_letter(['ghi', 'def', 'abc']) > def b(): return 546465465454 > print(b) > sort_by_last_letter(['ghi', 'def', 'abc']) > > and memory gets reused a different way. > > .last_letter at 0x03A51D40> > # <== is same memory as . > .last_letter at 0x043C2710> > # ditto > .last_letter at 0x043C2768> > > Creating a new list or string did not have the same effect. I believe > that CPython function objects must currently all have the same size or > at least the same max size and conclude that CPython currently allocates > them from a block of memory that is some multiple of that size. These > are, of course, current internal implementation details, subject to > change and even variation across hardware and OSes. > > -- > Terry Jan Reedy > > > > > > -- Forwarded message -- > From: Martin De Kauwe > To: python-list@python.org > Cc: > Bcc: > Date: Fri, 15 Mar 2019 15:17:22 -0700 (PDT) > Subject: subprocess svn checkout password issue > Hi, > > I'm trying to write a script that will make a checkout from a svn repo and > build the result for the user. However, when I attempt to interface with > the shell it asks the user for their filename and I don't know how to > capture this with my implementation. > > user = "XXX578" > root="https://trac.nci.org.au/svn/cable; > repo_name = "CMIP6-MOSRS" > > cmd = "svn check
[issue32810] Expose ags_gen and agt_gen in asynchronous generators
Change by Keith Dart : -- nosy: +kdart ___ Python tracker <https://bugs.python.org/issue32810> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34175] typing.NamedTuple: type-checking error when "index" used as member
Keith Campbell added the comment: > It's up to the OP to file an issue there though Will do; thanks! -- ___ Python tracker <https://bugs.python.org/issue34175> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34175] typing.NamedTuple: type-checking error when "index" used as member
New submission from Keith Campbell : Find the test case below: from typing import NamedTuple class Foo(NamedTuple): alpha: int index: int This results in the following error when run through type-checking with mypy: % mypy --version mypy 0.620 % mypy go.py go.py:5: error: Incompatible types in assignment (expression has type "int", base class "tuple" defined the type as "Callable[[Tuple[int, ...], Any, int, int], int]") When I instantiate this class in the python interpreter, I have no problem accessing the "index" member, so I suspect this is a bug in the type checker. -- components: Library (Lib) messages: 322038 nosy: campkeith priority: normal severity: normal status: open title: typing.NamedTuple: type-checking error when "index" used as member versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue34175> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24132] Direct sub-classing of pathlib.Path
Keith <kei...@consultant.com> added the comment: Look at the architecture of Rio in Ruby (also ported to Squeak/Smalltalk) Leave Path to handle path stuff, and have another class to handle Platform stuff. https://rubygems.org/gems/rio/versions/0.6.0 -- nosy: +keithy ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue24132> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5710] ctypes should return composite types from callbacks
Russell Keith-Magee <freakboy3...@gmail.com> added the comment: For those interested, we developed a workaround for this in Rubicon: https://github.com/pybee/rubicon-objc/pull/85/files The fix involves using ctypes to access ctypes own internals, and build a modified version of the Structure data type that is able to perform a copy when used as returned value. Hopefully we'll be able to get this into the form of a patch for ctypes that is acceptable to Python core. -- nosy: +freakboy3742 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue5710> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23670] Modifications to support iOS as a cross-compilation target
Russell Keith-Magee <freakboy3...@gmail.com> added the comment: For those interested, I've started tracking these patches on Github: https://github.com/freakboy3742/cpython The 3.4, 3.5 and 3.6 branches are tested and compile as of the time of this comment; the master branch has also been updated, in preparation for the release of 3.7. I haven't submitted pull requests because there are still some issues that Ned raised in discussions at PyCon US. -- versions: +Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue23670> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30034] csv reader chokes on bad quoting in large files
Keith Erskine added the comment: OK Terry. Thank you everybody for your thoughts and suggestions. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30034> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30034] csv reader chokes on bad quoting in large files
Keith Erskine added the comment: I should have said, Peter, an odd number of quotes does not necessarily mean the quoting is bad. For example, a line of: a,b",c will parse fine as ['a', 'b"', 'c']. Figuring out bad quoting is not easy, but if we know that there are no multiline fields in the file, then at least the parsing can stop at the end of the line. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30034> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30034] csv reader chokes on bad quoting in large files
Keith Erskine added the comment: The csv reader already supports bad CSV - that's what I believe "strict" is for - but only in one specific scenario. My request is to make that "strict" attribute a bit more useful. Thank you for your suggestion, Peter. I have toyed with the idea of looking for an even number of double quotes in each line, but thank you for your neat way of encapsulating it. (I already have to strip null bytes out of the input data because they break csv, see issue #27580). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30034> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30034] csv reader chokes on bad quoting in large files
Keith Erskine added the comment: As you say, David, however much we would like the world to stick to a given CSV standard, the reality is that people don't, which is all the more reason for making the csv reader flexible and forgiving. The csv module can and should be used for more than just "comma-separated-values" files. I use it for all sorts of different delimited files, and it works very well. Pandas uses it, as I'm sure do many other packages. It's such a good module, it would be a pity to restrict its scope to just Excel-related scenarios. Parsing delimited files is undoubtedly complex, and painfully slow if done with pure Python, so the more that can be done in C the better. I'm no C programmer, but my guesstimate is that the coding changes I'm proposing are relatively modest. In the IN_QUOTED_FIELD section (https://github.com/python/cpython/blob/master/Modules/_csv.c#L690), it would mean checking for newline characters if the new "multiline" attribute is False (and probably "strict" is False too). Of course there is more to this change than just that, but I'm guessing not that much more. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30034> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30034] csv reader chokes on bad quoting in large files
Keith Erskine added the comment: The csv reader already handles a certain amount of bad formatting. For example, using default behavior, the following file: a,b,c d,"e"X,f g,h,i is read as: ['a', 'b', 'c'] ['d', 'eX', 'f'] ['g', 'h', 'i'] It seems reasonable that csv should be able to handle delimited files that are not perfectly formatted. After all, even the CSV "standard" isn't really a standard. When dealing with large (10GB+) files, it's a pain if csv cannot read the file because of just one misplaced quote character. Besides, data files are only going to get bigger. Also, I have to say, I've been dealing with large ETL jobs for over 15 years now and I'm struggling to think of a time when I've ever seen a multiline CSV file. Of course, we've all have different experiences. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30034> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30034] csv reader chokes on bad quoting in large files
Keith Erskine added the comment: Perhaps I should add what I would prefer the csv reader to return in my example above. That would be: ['a', 'b', 'c'] ['d', 'e,f'] ['g', 'h', 'i'] Yes, the second line is still mangled but at least the csv reader would carry on and read the third line correctly. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30034> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30034] csv reader chokes on bad quoting in large files
New submission from Keith Erskine:
If a csv file has a quote character at the beginning of a field but no closing
quote, the csv module will keep reading the file until the very end in an
attempt to close out the field. It's true this situation occurs only when the
quoting in a csv file is incorrect, but it would be extremely helpful if the
csv reader could be told to stop reading each row of fields when it encounters
a newline character, even if it is within a quoted field at the time. At the
moment, with large files, the csv reader will typically error out in this
situation once it reads the maximum size of a string. Furthermore, this is not
an easy situation to trap with custom code.
Here's an example of the what I'm talking about. For a csv file with the
following content:
a,b,c
d,"e,f
g,h,i
This code:
import csv
with open('file.txt') as f:
reader = csv.reader(f)
for row in reader:
print(row)
returns:
['a', 'b', 'c']
['d', 'e,f\ng,h,i\n']
Note that the whole of the file after "e", including delimiters and newlines,
has been added to the second field on the second line. This is correct csv
behavior but is very unhelpful to me in this situation.
On the grounds that most csv files do not have multiline values within them,
perhaps a new dialect attribute called "multiline" could be added to the csv
module, that defaults to True for backwards compatibility. It would indicate
whether the csv file has any field values within it that span more than one
line. If multiline is False, then the "parse_process_char" function in "_csv"
would always close out a row of fields when it encounters a newline character.
It might be best if this multiline attribute were taken into account only when
"strict" is False.
Right now, I do get badly-formatted files like this, and I cannot ask the
source for a new file. I have to manually correct the file using a mixture of
custom scripts and vi before the csv module will read it. It would be very
helpful if csv would handle this directly.
--
messages: 291453
nosy: keef604
priority: normal
severity: normal
status: open
title: csv reader chokes on bad quoting in large files
type: enhancement
versions: Python 3.7
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30034>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Elastic Search
I need some insightful examples of elastic search, using REGEX ... And using REST. -- https://mail.python.org/mailman/listinfo/python-list
[issue29073] bytearray.__mod__() truncates on first \x00
Russell Keith-Magee added the comment: Since I was named dropped; it's worth pointing out that this has evidently been fixed - intentionally or otherwise - in 3.6. It wasn't an issue in 3.4 and earlier because __mod__ wasn't implemented for bytestrings. -- nosy: +freakboy3742 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29073> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26223] decimal.to_eng_string() does not implement engineering notation in all cases.
Keith Brafford added the comment: Serge, I wrote this awhile back, before I learned you aren't supposed to subclass built-in types. Is this the type of effect you're looking for? https://gist.github.com/kbrafford/da39e06d18b6df2a0eecb4493699 Here's an example using it: https://gist.github.com/kbrafford/e0115e796890fcefb4f0c35248bd05f1 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26223> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23968] rename the platform directory from plat-$(MACHDEP) to plat-$(PLATFORM_TRIPLET)
Changes by Russell Keith-Magee <freakboy3...@gmail.com>: -- nosy: +freakboy3742 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23968> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23670] Modifications to support iOS as a cross-compilation target
Russell Keith-Magee added the comment: Yes - I'm aware of Pythonista; the author of that app contracted me to develop the 3.5 patch that is attached to this ticket :-) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23670> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23670] Modifications to support iOS as a cross-compilation target
Russell Keith-Magee added the comment: Alex - The usual cause for that problem isn't regrtest (at least, not directly). The cause is one of the tests in the suite spawning a subprocess. Due to the way the test harness works, when the test suite forks/spawns a subprocess (e.g., to run a network server or a multiprocess worker), the fork causes the a second version of the test suite to start, rather than starting the server subprocess. I've attached a patch for 3.5.1. This includes a patch to work around Issue22625; the patch is definitely suboptimal, but it lets a build come to completion. What is really needed (as requested on python-dev) is some help working out how to fix Issue22625 properly. -- versions: +Python 3.5 Added file: http://bugs.python.org/file42060/20160217.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23670> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26186] LazyLoader rejecting use of SourceFileLoader
Changes by Keith Dart <ke...@dartworks.biz>: -- nosy: +kdart ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26186> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23670] Modifications to support iOS as a cross-compilation target
Russell Keith-Magee added the comment: Another update - the issue with libffi has been resolved, so there is now only need for a single copy of libffi_ios sources. This directory could potentially be merged with the libffi_osx sources, except that libffi no longer supports PowerPC as a compilation target for OS/X builds (and neither does Apple). If PowerPC can be dropped from the list of supported platforms, libffi for OS X can be updated to the current trunk sources. -- versions: +Python 3.4 -Python 3.5 Added file: http://bugs.python.org/file41376/20151221.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23670> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25836] Documentation of MAKE_FUNCTION/MAKE_CLOSURE_EXTENDED_ARG is misleading
Russell Keith-Magee added the comment: It turns out I wasn't completely correct. As per my second point, the interpretation of annotations needs be clarified, but my first point about default_args including the annotation count is incorrect. My error was made because of the documentation for EXTENDED_ARG. The current text implies that you need to combine the argument value of the EXTENDED_ARG opcode with the argument value for the previous opcode. However if you're using dis.Bytecode() to extract bytecodes, that composition is done for you - you can effectively ignore the EXTENDED_ARG opcode. -- title: Documentation of MAKE_FUNCTION is still incorrect -> Documentation of MAKE_FUNCTION/MAKE_CLOSURE_EXTENDED_ARG is misleading ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25836> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25836] Documentation of MAKE_FUNCTION is still incorrect
New submission from Russell Keith-Magee: Refs Issue16554, Issue13026, Issue14349, and probably others. The documentation for the interpretation of the argc argument to MAKE_FUNCTION in Doc/library/dis.rst is incorrect. As of 13 August 2015, the docs say: """ Pushes a new function object on the stack. From bottom to top, the consumed stack must consist of: * ``argc & 0xFF`` default argument objects in positional order * ``(argc >> 8) & 0xFF`` pairs of name and default argument, with the name just below the object on the stack, for keyword-only parameters * ``(argc >> 16) & 0x7FFF`` parameter annotation objects * a tuple listing the parameter names for the annotations (only if there are ony annotation objects) * the code associated with the function (at TOS1) * the :term:`qualified name` of the function (at TOS) """ However, this doesn't capture the fact that: * if there are annotations, the number of default arguments returned by `argc & 0xFF` must be reduced by `(argc >> 16) & 0x7FFF` * The value `(argc >> 16) & 0x7FFF` for the number of annotations *includes* the "extra" entry for the tuple describing which arguments the annotations apply to. This means that `(argc >> 16) & 0x7FFF` will be either 0, or 2+; it can't be 1 (because if you have one annotation, you must also have a tuple describing which arguments is annotated). -- assignee: docs@python components: Documentation messages: 256189 nosy: docs@python, freakboy3742 priority: normal severity: normal status: open title: Documentation of MAKE_FUNCTION is still incorrect versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25836> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25836] Documentation of MAKE_FUNCTION is still incorrect
Changes by Russell Keith-Magee <freakboy3...@gmail.com>: -- versions: -Python 2.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25836> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Is Microsoft Windows secretly downloading childporn to your computer ?!
Juha Nieminen <nospam@thanks.invalid> writes: > In comp.lang.c++ Steve Hayes <hayes...@telkomsa.net> wrote: >> You download things FROM a computer, you upload them TO a computer. > > It's a matter of perspective. If a hacker breaks into your computer and > starts a download from somewhere else into your computer, isn't the hacker > "downloading" things to your computer? My understanding of the word "downloading" has always been STOP FEEDING THE TROLL! -- Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst> Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister" -- https://mail.python.org/mailman/listinfo/python-list
Re: Is Microsoft Windows secretly downloading childporn to your computer ?!
Steve Hayes <hayes...@telkomsa.net> writes: > On Tue, 1 Dec 2015 03:19:39 +0100, "Skybuck Flying" > <skybuck2...@hotmail.com> wrote: >>The question is: >> >>Is Microsoft [snip] > > You download things FROM a computer, you upload them TO a computer. > > Since you don't even know that much about computers, anything else you > say is obviously not worth readin. Nor is it worth replying to. *Please* don't feed the troll. (Followups set.) -- Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst> Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister" -- https://mail.python.org/mailman/listinfo/python-list
[issue25682] __package__ not set to None under pdb in Python 3
New submission from Keith Prussing: When a module is run under pdb in Python 3, __package__ is set to the empty string instead of None. The attached minimum working example depicts this behavior. The results are summarized in the following table. === == == Command Py 2 Py 3 === == == python None None python -m'' '' python -m pdb None'' pdb None'' === == == The behavior I expected was for the Python executable to treat the input file as a script and not a module. My rationale is that pdb is loaded as the executing module that accepts a script as its argument. Per the help, only one -m option is allowed when launching python. -- components: Extension Modules files: mwe.py messages: 254989 nosy: Keith Prussing priority: normal severity: normal status: open title: __package__ not set to None under pdb in Python 3 type: behavior versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file41099/mwe.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25682> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8231] Unable to run IDLE without write-access to home directory
Keith Teal added the comment: I would also like to add that the location of this directory is not correct for Windows software. This directory should be created in %APPDATA% where users by default do have write permissions. If there are plans to ever make this application portable then it should support a command line option to specify the location of the configuration as well. -- nosy: +tealduck ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8231] Unable to run IDLE without write-access to home directory
Keith Teal added the comment: Hi Terry, I did not just make that stuff up on my last post, that is actually the standard for Windows applications. Yes, many Linux ports get it wrong but is that any reason to ever perpetuate a bad practice? To see the standards you can download the Windows SDK but to make things easier for you here is a link that talks about this: http://blogs.msdn.com/b/patricka/archive/2010/03/18/where-should-i-store-my-data-and-configuration-files-if-i-target-multiple-os-versions.aspx By using non-standard conventions the application is just asking for trouble like what is being manifested with this issue. Users will be able to write to their %APPDATA% area, no administrator would lock that down as it would cause too many applications to fail (Kiosk type installations not included). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23496] Steps for Android Native Build of Python 3.4.2
Russell Keith-Magee added the comment: What hardware architecture are you compiling for? If it's ARM64, and you're not using a trunk version of libffi, that segfault in test_ctypes is to be expected. Does this mean I can safely ignore the segfault? Well, safely in the sense that everything except a very recent version of libffi is known to not work on ARM64 - so if it doesn't work, it's not because of something Python is doing wrong, it's a problem with a dependency. Are you using the libffi sources vendored into the Python source tree, or a more recent version? By 'vendored in' do you mean 'sources included in python source tree for building?' Correct. The libffi source code that is in the Python source tree is quite old, and *definitely* doesn't work on ARM64. I'm not even sure that it works on ARMv7. I can verify that libffi v3.2 works on ARMv7 (on iOS, anyway), and there's been plenty of changes to the ARM source tree since the Python version was vendored in. Would your recommend downloading and building libffi from sources (on device) and then building python? Well, for starters - as I've said before, I'd recommend not compiling on device at all, but that's a separate issue. However, regardless of where you're compiling, you can either use an external libffi, or you can do what I've done in the iOS patch - update the Python source tree to include a newer version of libffi. If you update the source in the Python tree, you need to use 2 versions (or a merged version); you need v3.2 sources for ARMv7, and trunk sources for ARM64. This is because libffi v3.2 doesn't work for ARM64, and trunk doesn't even compile for ARMv7. See the iOS patch for details. I'm asking the above questions because I've hit a fairly significant roadblock; I'm still getting the segfault when test_ctypes is run and I can't seem to get anything useful out of gdb. Personally, I've pretty much given up on CPython on Android. Even when I got it working, the performance of the JNI layer is *abysmal*, and severely crippled. If you're planning to actually interact with the device in any way (like, say, put a button on the screen), that's a big problem. I'm working on an approach that uses Java natively - think Jython for Android. I'm still a way off having anything working, though. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23496 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23496] Steps for Android Native Build of Python 3.4.2
Russell Keith-Magee added the comment: Are you using the libffi sources vendored into the Python source tree, or a more recent version? I can verify that libffi v3.2 works on ARMv7 (on iOS, anyway), and there's been plenty of changes to the ARM source tree since the Python version was vendored in. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23496 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23496] Steps for Android Native Build of Python 3.4.2
Russell Keith-Magee added the comment: What hardware architecture are you compiling for? If it's ARM64, and you're not using a trunk version of libffi, that segfault in test_ctypes is to be expected. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23496 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23670] Modifications to support iOS as a cross-compilation target
Russell Keith-Magee added the comment: Another update - this time, there are only 4 failing tests on device, all related to ctypes issues. The sample Xcode project and iOS-test harness have been modified, simplifying the project layout, and using Apple-preferred directories for resources when deployed to device. -- Added file: http://bugs.python.org/file39862/20150704.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23670 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23670] Modifications to support iOS as a cross-compilation target
Russell Keith-Magee added the comment: Another patch update - the code now passes the full Python test suite on the iOS simulator. There are still a couple of failures on device; as before, these appear to be due to ctypes problems and a permissions issue with os.mkdir. -- Added file: http://bugs.python.org/file39824/20150628.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23670 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23670] Modifications to support iOS as a cross-compilation target
Russell Keith-Magee added the comment: This new patch (20150504.diff) adds support for running the Python test suite The new patch is standalone, and contains everything in the previous patch. An XCode project (Tools/iOS-test) has been added to the source tree; this project contains bootstrap C code to start and run the full Python regression test suite. There's also a new target in the iOS/Makefile meta-buildfile - make test - which will compile a debug version of the Python framework, and install it into the iOS-test project. Getting the test suite to run has revealed one major limitation of the iOS platform - system calls like fork, exec*, and spawn* don't work. The OS calls *exist* at an API level - but if you use them, they either crash, or they lock up the device while you wait for a subprocess that will never execute. This makes sense considering the platform itself - there's no such thing as a background process in iOS; background tasks are very heavily sandboxed. A number of other minor problems have been identified as a result of running the full test suite; they have been addressed in the patch. The test suite still has 5 failures on the simulator. I'm investigating the cause of these failures. There's a couple of more failures on a physical device - 13 failures in total. These device-specific failures appear to be largely due to ctypes problems and a permissions issue with os.mkdir. If you run the test suite in XCode as a debug binary, the debugger will stop whenever a SIGPIPE, SIGINT, SIGXFSZ, SIGUSR1 or SIGUSR2 signal is raised. You can just hit continue in the debugger, and the test will continue. To work around this, you need to run the following debugger commands before the first signal is raised: process handle SIGPIPE -n true -p true -s false process handle SIGINT -n true -p true -s false process handle SIGXFSZ -n true -p true -s false process handle SIGUSR1 -n true -p true -s false process handle SIGUSR2 -n true -p true -s false I've been doing this by setting a breakpoint in the main.c method; I'm investigating other ways to automate this. -- Added file: http://bugs.python.org/file39286/20150504.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23670 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24109] Documentation for difflib uses optparse
Keith Gray added the comment: I took a look at Tools/scripts/diff.py and it looks like it got converted to use argparse 9 months ago. I think I should be able to just include that in the difflib documentation directly. My next question is which branches need to have this changed? Do I just make the documentation change to the default branch or do I need to change it in 2.7, 3.2, 3.3, and 3.4 as well? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24109 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24109] Documentation for difflib uses optparse
Keith Gray added the comment: Here is the patch. I have tested it against tip. Let me know if you need anything else. -- keywords: +patch Added file: http://bugs.python.org/file39268/issue-24109.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24109 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24109] Documentation for difflib uses optparse
New submission from Keith Gray: The documentation for optparse states it has been deprecated in favor of argparse since 2.7. However, the library documentation for difflib still uses optparse in the example. https://docs.python.org/2/library/difflib.html#a-command-line-interface-to-difflib https://docs.python.org/3.5/library/difflib.html#a-command-line-interface-to-difflib I am willing to update the documentation if there is agreement that it is needed. -- assignee: docs@python components: Documentation messages: 242347 nosy: docs@python, idahogray priority: normal severity: normal status: open title: Documentation for difflib uses optparse type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24109 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23670] Modifications to support iOS as a cross-compilation target
Russell Keith-Magee added the comment: Here's an updated patch that integrates some of the feedback that has been received so far. Notable changes: * The code now works for ARMv7. Unfortunately, the price for this is a new libffi_ios_aarch source directory, containing generated source tree for the ARM64 platform. I've been working with the libffi community to address the compilation problems that exist in trunk, but so far, this hasn't resulted in a fix for the problems that have been introduced in their trunk code. * I looked into merging the libffi_ios and libffi_osx directories, but this proved to be harder I thought because of legacy PowerPC support. libffi still ships PowerPC sources, but they're no longer included in OS/X builds, because Apple stopped supporting PowerPC with OS/X 10.6 (released in 2009; the last PowerPC Apple hardware was shipped in 2006). As a result, it's difficult to find compilation instructions, and even harder to find actual hardware to test builds. If support for PowerPC architectures (on OS/X) was deprecated, this would make merging the libffi_ios and libffi_osx a trivial activity. * I've audited plat_ios/IN.py, and can now confirm that it *is* identical between platforms. * I have looked into replacing Setup.* with some sort of post-configure procedure as suggested by @doko. Unfortunately, it's not that simple. The problem is that there is already 2 places where the build requirements for a built-in module are defined. Modules/Setup contains one set of instructions (although those instructions are often commented out). The second set is hard coded into setup.py. The versions in setup.py are probably more reliable (as they're the ones actually used for most platforms), but you need to have a working Python to access them. However, at the post-configure point, you don't have a working Python, so there's a bootstrapping problem. I've refactored the Setup.ios-* definitions so that there's less duplication. There's now a Setup.embedded that contains the common build instructions for all the modules without platform-specific build instructions. Setup.ios-* just contains the platform-specific build instructions (in much the same way as setup.py has configure_ctypes_darwin). To work around this completely, we'd need to either introduce the need for a bootstrap Python so that a post-configure setup could access the build instructions contained in setup.py, or massively refactor the process of building modules so that there was a set of build instructions that both makesetup and setup.py could use. -- Added file: http://bugs.python.org/file39207/20150426.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23670 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23670] Modifications to support iOS as a cross-compilation target
Russell Keith-Magee added the comment: Hi Matthias: * The libffi situation on iOS is much the same as it is on OS/X - it needs to be pre-generated. This can't be driven by the existing build system - libffi's Makefile requires a separate pre-generation step. There's certainly potential for reuse between the OS/X and iOS generated files, though - there's no reason I couldn't merge the libffi_ios tree into the libffi_darwin tree - they reuse a lot of the same code for the x86-64 platform. * Regarding Setup.* - if shipping specific Setup.* files is a problem, I can certainly look at enhancing the makesetup process to generate these, rather than shipping generated files. * I'll add a comment to the setup.py change. Essentially, it's an edge case of the current setup.py - if you don't have *any* external modules, the current logic breaks evaluating the size of the columns to use when displaying external modules that haven't been compiled - although it's displaying the list of *missing* modules, it uses the longest name in the *existent* extensions to determine the display column width. * The Plat_ios constants certainly appear to be the same for all platforms; admittedly, though, I haven't done a thorough audit of this. I'll put this on my todo list. * The build triples are armv7-apple-ios for older 32 bit iOS devices, aarch64-apple-ios for newer 64 bit devices, and x86_64-apple-ios on the simulator. Builds for armv6-apple-ios and armv7s-apple-ios are also plausible, but armv7 and aarch64 is what XCode supports as a default configuration at present. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23670 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23670] Modifications to support iOS as a cross-compilation target
Russell Keith-Magee added the comment: Nick: Finding a way to get on-device test results is next on my TODO list, once I've got the patch up to date for trunk. FYI - Updating to trunk is currently blocking on issue22625 (which was introduced by the fix for issue22359). I had thought about using a mobile testing farm as a service, but I didn't know Sauce Labs had one. I'll keep that in mind when I get around to working on the test suite. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23670 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22625] When cross-compiling, don’t try to execute binaries
Russell Keith-Magee added the comment: I'm looking into this issue because of issue23670 (iOS support). Am I correct in assuming that the right fix here is to identify a $(CC_FOR_BUILD) analog for $(PYTHON_FOR_BUILD) that will identify the build host's CC, enabling a build-host native $(PGEN) and _freeze_importlib to be compiled? -- nosy: +freakboy3742 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22625 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23670] Modifications to support iOS as a cross-compilation target
Russell Keith-Magee added the comment: Nick: you are correct - these are changes to support iOS as a cross-compilation target, so you can run your Python code on an iOS device. Apologies for the confusion in nomenclature. Ned: You're correct that the build needs to be run on an OS/X machine, and needs to be done in multiple passes because of the need for multiple SDKs. I've taken the approach of using Setup.local for two reasons. Firstly, iOS requires a fully embedded Python, because Apple doesn't approve of the use of dynamic loading in apps. Setup.local was the best way I found to force modules to be statically linked into the main library. Secondly, because of the nature of the end-deployment, I imagine it's inevitable that serious end-users will want to customise their Python build for specific applications. AppStore submission rules prohibit running code that wasn't shipped with the app (i.e., Apple won't let you do an end-run around their app approval processes), so the set of modules you're actually using will be a known quantity. Since a full iOS Python build is 34MB or so, much of that bulk will be for binary support of modules that you aren't using, providing an easily configurable way to prune out unused modules from the built product seemed like a useful facility. There's also the issue of providing support for the standard library modules (like SSL) that have dependencies that can't be easily provided or specified out-of-the-box. If there's a better/more palatable approach than using Setup.local, I'm happy to look into it. The libffi code is a direct copy from the current (as of a week or so ago) libffi trunk. There have been some bug fixes applied since 3.2.1 was released in november that are necessary to support ctypes on ARM64 (but, as I flagged in my original comment, introduces bugs for ARMv7). The libffi repo suggests the next version will be 4.0, but I have no idea when that will be finalised. I'm currently trying to get their release plans confirmed. As with OS/X libffi support, the source code needs to be generated, rather than just ./configure make'd. That said, the libffi_darwin code could be re-used, as the x86_64 components are the same for Darwin as the iOS simulator. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23670 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23670] Modifications to support iOS as a development platform
New submission from Russell Keith-Magee: Proposal: iOS should be a supported platform for Python development. The attached patch is a first pass at a patch to achieve this. It is a single patch against Python 3.4.2 sources, and requires no pre- or post-configure modifications. Supporting iOS requires multiple builds - one for each of the hardware platforms that iOS supports (x86_64 simulator, ARMv7 and ARM64). These separate builds must then be merged into a single fat framework. The patch contains an iOS directory with a meta Makefile that manages this build-and-merge process. See the README in the iOS directory for details on usage. The patch also introduces a new 'ios' platform type. A sample XCode project for an iOS app is also provided as part of the patch. iOS/README contains a couple of other notes about the build and the approach taken. There are some known problems/limitations with this patch: * It's a patch against 3.4.2, not hg trunk * The code doesn't currently compile for ARMv7. In order to support ARM64, it has been necessary to use an unreleased trunk version of libffi; however, this version is currently broken for ARMv7. Older versions of libffi (including the formal 3.2.1 release) *do* work. * The patch doesn't currently provide any way to run the test suite on the target platform. Testing is currently based on a simple smoke test of some basic features. So - the patch isn't ready for commit to trunk. I'm presenting it for the purposes of getting feedback on the broad approach while I continue to resolve the known issues. -- components: Build, Cross-Build files: 20150314.diff keywords: patch messages: 238125 nosy: freakboy3742 priority: normal severity: normal status: open title: Modifications to support iOS as a development platform type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file38493/20150314.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23670 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23670] Modifications to support iOS as a cross-compilation target
Russell Keith-Magee added the comment: Understood that buildbots are required. The subject has come up a couple of times on mobile-sig - however, I haven't got a good answer for exactly what this means in practice. Does build hardware need to be delivered to a specific build farm location, or can it just run in my home office? Does it need to be running 24/7, or just guarantee that at least X builds per week, or Y% of all builds are tested? In terms of physical specifications - at a minimum, at least two iDevices will be required (an ARMv7 device, like a 5th Gen iPod, and an ARM64 device, like an iPhone 5S), tethered to a Mac that runs the simulator. In terms of execution - there's definitely ways to remote-control the deployment and execution of apps, so I imagine buildbot integration is in the realm of the possible. Android will have similar requirements, but Android also has an emulator which would allow testing without the existence of a physical device, which would provide an alternative approach. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23670 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23496] Steps for Android Native Build of Python 3.4.2
Changes by Russell Keith-Magee freakboy3...@gmail.com: -- nosy: +freakboy3742 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23496 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23087] Exec variable not found error
New submission from Keith Chewning:
If I %paste this code into an ipython shell the test passes. If this is saved
to a file DictTest.py and run with ./DictTest.py -m the test fails. with the
error
name 'keys' is not defined
If the variable keys is made global, as is suggested in the comment, the test
passes with both methods of execution. Is there a scoping issue with executing
this as a script?
I am using version: '3.4.1 |Anaconda 2.1.0 (64-bit)| (default, Sep 10 2014,
17:10:18) \n[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)]'
import unittest
class DictTest(unittest.TestCase):
def test_dict_comprehension(self):
code =
d = {'a':1, 'b':2, 'c':3, 'd':4}
# global keys # UNCOMMENT FOR TEST TO PASS
keys = ['a', 'd']
items = d.items()
nd = {k: v for k, v in items if k in keys}
print(' ' + str(nd))
try:
exec(code)
except Exception as e:
self.assertTrue(False, Exec ERROR %s % e)
def main():
dt = DictTest()
dt.test_dict_comprehension()
if __name__ =='__main__':main()
--
messages: 232907
nosy: Keith.Chewning
priority: normal
severity: normal
status: open
title: Exec variable not found error
type: behavior
versions: Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23087
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15125] argparse: positional arguments containing - in name not handled well
Keith Hughitt added the comment: Although it would be nice if the behavior were normalized between positional and optional args, it seems like doc patch would be the most straight-forward at this point. The down-side is that I suspect many people will assume the behavior for optional args, have it fail, and then consults the docs to see what happened. I would suggest making the note pretty obvious or early on in the docs for argparse. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15125 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15125] argparse: positional arguments containing - in name not handled well
Keith Hughitt added the comment: Any progress on this issue? Still persists in Python 3.4.1. -- nosy: +khughitt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15125 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20543] ** operator does not overflow to inf
New submission from Keith Randall: 1e200*1e200 inf 1e200**2 Traceback (most recent call last): File stdin, line 1, in module OverflowError: (34, 'Numerical result out of range') Shouldn't floating-point operations overflow to inf, not generate exceptions? -- components: Interpreter Core messages: 210517 nosy: Keith.Randall priority: normal severity: normal status: open title: ** operator does not overflow to inf type: behavior versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20543 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11077] Tkinter is not thread safe
Keith Bannister added the comment: Hi, I'm trying to make an application with GNU readline support, and some plots. But it seems that tkInter and raw_input don't play nicely. The attached script (18 lines) crashes immediately on my Mac with SIGABRT and outputs the following: $ python tk_v_raw.py Yes? Tcl_WaitForEvent: Notifier not initialized Abort trap: 6 Is this related to this issue? -- nosy: +Keith.Bannister Added file: http://bugs.python.org/file33637/tk_v_raw.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11077 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16727] Windows installers for 2.7.3 don't install python27.dll correctly
Keith Sabine added the comment: Well all I can say is having installed BOTH the 32 and 64 bit versions, I found I only had the 32 bit dll installed. I can raise a second issue for the request to put a copy of the dll in the DLL directory, so that it's easier to locate the correct dll if needed to ship with an embedded python application. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16727 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16727] Windows installers for 2.7.3 don't install python27.dll correctly
New submission from Keith Sabine: The windows installers for Python 2.7.3 do not install the required python27.dll correctly. The Windows x86 MSI Installer (2.7.3) does not install a 32 bit python27.dll in windows\system32 at all. The Windows x86-64 MSI Installer (2.7.3) installs a 64 bit python27.dll in windows\system32, NOT in windows\SysWOW64 as it should. The python27.dll should be kept in the python DLLs directory for both 32 and 64 bit versions, so users can clean up the mess if they need to... -- components: Windows messages: 177736 nosy: keith969 priority: normal severity: normal status: open title: Windows installers for 2.7.3 don't install python27.dll correctly versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16727 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16727] Windows installers for 2.7.3 don't install python27.dll correctly
Keith Sabine added the comment: I selected install for all users, even though there is only one... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16727 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Pass a list of variables to a procedure
Thank you, Chris! Sent from my iPhone On Apr 7, 2012, at 3:24 PM, Chris Rebert c...@rebertia.com wrote: On Sat, Apr 7, 2012 at 2:15 PM, KRB alaga...@gmail.com wrote: Hi there, I would like to be able to pass a list of variables to a procedure, and have the output assigned to them. You cannot pass a variable itself to a function; you can only pass a variable's value. Which is to say that Python doesn't use pass-by-reference. Without using black magic, a Python function cannot rebind variables in its caller's scope. Mutable values can be mutated however. Details: http://effbot.org/zone/call-by-object.htm For instance: x=0 y=0 z=0 vars =[x,y,z] parameters=[1,2,3] for i in range(1,len(vars)): *** somefunction that takes the parameter 1, does a computation and assigns the output to x, and so on and so forth. Such that later in the program I can print x,y,z I hope that makes sense, otherwise I have to do: x=somefunction(1) y=somefunction(2) z=somefunction(3) etc etc Just use sequence (un)packing: def somefunction(*parameters): # one would normally use a list comprehension here; # for simplicity, I'm not results = [] for parameter in parameters: result = do_some_calculation(parameter) results.append(result) return results #…later... x, y, z = somefunction(1, 2, 3) Relevant docs: http://docs.python.org/tutorial/datastructures.html#tuples-and-sequences http://docs.python.org/tutorial/controlflow.html#tut-unpacking-arguments Cheers, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: xlrd 0.7.6 released!
Karim kliat...@gmail.com wrote in news:mailman.1309.1333529851.3037.python-l...@python.org: This release manage the '.xlsx' format? http://packages.python.org/openpyxl/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Cannot connect to IMAP server in Python 3.2
Steve Howell showel...@yahoo.com wrote in news:ae774035-9db0-469d-aa2a- 02f2d25ff...@qg3g2000pbc.googlegroups.com: Once you are able to import ssl, you should be able to use IMAP4_SSL, but that still doesn't entirely explain to me why you got a timeout error with plain IMAP4 and the proper port. (I would have expected a failure, but of a different kind.) Connecting to the SSL socket requires that one initiate the TLS handshake forthwith. Establishing a connection to an I expect SSL from the get- go using a protocol that speaks I am a normal unencrypted socket but you can initiate TLS using the starttls command is not the same thing. In other words, you are violating the requirements of the protocol, and you are timing out. This is because the first protocol step in a standard connection is to wait for the plain-text greeting, where the first step in connecting to the SSL socket is to do a TLS dance, then initiate the IMAP protocol by sending the greeting. If you connect with a non-SSL initiator to an SSL endpoint, you will get a timeout. If you connect with an SSL initiator to a non-SSL endpoint, you will timeout. It is not the connection that is timing out, it is the protocol. I'd still be curious to see what happens when you try this: import socket, imaplib your_host_name = # ... socket.create_connection((your_host_name, imaplib.IMAP4_SSL_PORT)) This will, of course, work just fine. You will not see a +Hello however until you have completed the TLS negotiation. -- http://mail.python.org/mailman/listinfo/python-list
[issue7133] test_ssl failure
Keith Briggs kbri...@users.sourceforge.net added the comment: Senthil: thanks for the reply. That's how I did build python 2.7.2 anyway. But I can't see anything about SSL in the generated config files.However, on another system (Fedora 15 with python 2.7.1), I don't get the problem. In case it's useful, I was trying to run the recipe http://code.activestate.com/recipes/573444-threaded-documenting-xml-rpc-server-over-https/?c=13559 when this crash happened. Is there something in that recipe which is not compatible with the current python modules? Keith -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7133 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11472] upload command fails to read auth information from .pypirc
Russell Keith-Magee freakboy3...@gmail.com added the comment: This isn't just a Python 3 issue -- I'm seeing this with the default Python install on OS X Snow Leopard (i.e. Python 2.6.1). Changing the .pypirc config line to [server-login] fixed the problem for me, too. -- nosy: +freakboy3742 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11472 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7133] test_ssl failure
Keith Briggs kbri...@users.sourceforge.net added the comment: I am still getting this error with SocketServer in Python 2.7.2, even though it looks the same as was fixed in Issue7133: File /usr/local/lib/python2.7/SocketServer.py, line 284, in _handle_request_noblock self.process_request(request, client_address) File /usr/local/lib/python2.7/SocketServer.py, line 310, in process_request self.finish_request(request, client_address) File /usr/local/lib/python2.7/SocketServer.py, line 323, in finish_request self.RequestHandlerClass(request, client_address, self) File /usr/local/lib/python2.7/SocketServer.py, line 641, in __init__ self.finish() File /usr/local/lib/python2.7/SocketServer.py, line 694, in finish self.wfile.flush() File /usr/local/lib/python2.7/socket.py, line 303, in flush self._sock.sendall(view[write_offset:write_offset+buffer_size]) TypeError: must be string or read-only buffer, not memoryview Keith -- nosy: +kbriggs ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7133 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Kind of OT - Books on software development?
I do not have my library with me, but I remember a book that fits the bill exactly, is was from Microsoft Press, I think it was called Writing Solid Code Hope this helps, -EdK Ed Keith e_...@yahoo.com Blog: edkeith.blogspot.com --- On Wed, 5/25/11, Matty Sarro msa...@gmail.com wrote: From: Matty Sarro msa...@gmail.com Subject: Kind of OT - Books on software development? To: Python list python-list@python.org Date: Wednesday, May 25, 2011, 11:40 AM Hey everyone, I am looking at some projects coming up, which may or may not involve python. So I figured I would throw the question out there and see what everyone thinks. I am looking for some books on software engineering/development... something that discusses techniques from ideation, up through testing, QA, production, and then maintenance. Is there such a book? -Matthew -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Kind of OT - Books on software development?
--- On Wed, 5/25/11, Ed Keith e_...@yahoo.com wrote: I do not have my library with me, but I remember a book that fits the bill exactly, is was from Microsoft Press, I think it was called Writing Solid Code I have done some research at amazon.com, and while Writing Solid Code is an excellent book that I would also recommend highly, the book I was thinking of was Code Complete. -EdK Ed Keith e_...@yahoo.com Blog: edkeith.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Abandoning Python
Have you looked at Falcon (http://www.falconpl.org/)? It seems to have a lot of what you are looking for. I do not have much experience with it but I like what I've seen so far, except that there are not any third party tools or libraries libraries. Which is where Python shines. -EdK Ed Keith e_...@yahoo.com Blog: edkeith.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Testing changes to Python code on the fly: reload() + alternatives?
Hi all, I have a couple of questions that I was hoping people might be able to provide suggestions on. 1) Is it possible to reload a class using the reload() method? For instance, suppose you have the following files: my_module/ __init__.py MyClass.py #init.py from MyClass import MyClass #MyClass.py class MyClass: def __init__(self): print(Before...) Is it possible to load the class, change the print statement (e.g. print(after...)), and have the changes take effect right away? The above method does not work: In [1]: import my_module In [2]: my_module.MyClass() Before... Out[2]: my_module.MyClass.MyClass instance at 0x8f5d16c In [3]: reload(my_module) Out[3]: module 'my_module' from 'my_module/__init__.pyc' In [4]: my_module.MyClass() Before... Out[4]: my_module.MyClass.MyClass instance at 0x8fca1ec Is there anyway to make this work while keeping MyClass in the main my_module namespace? 2) More generally though, what is the best way to go about testing changes to code as you are writing it? It would be very convenient to be able to use reload() along the lines of the above so that I could test changes to a small part of some class/function/etc without having to reload the entire state from scratch. Another option of course would be to just run everything as a standalone script, but then you lose the ability to be able to easily inspect the objects you are working and change them on the fly, except perhaps by using PDB. Any suggestions would be greatly appreciated. Thanks! Keith -- http://mail.python.org/mailman/listinfo/python-list
