Decorater added the comment:
It seems there are some packages that supports the range requests too:
https://github.com/danvk/RangeHTTPServer
Not sure if that supports python 3 or not. It could be used to make a patch for
http.server though
New submission from Decorater :
I have issues with range requests on http.server module (ran from python -m
http.server command)
When requesting files to download from an program written in C (which uses
range requests to update an progress bar) it ignores this and simply forces
download of
Change by Decorater :
--
pull_requests: +8832
___
Python tracker
<https://bugs.python.org/issue25711>
___
___
Python-bugs-list mailing list
Unsubscribe:
Decorater added the comment:
Attached is my changes to the vcxproj files based on an field already in
python.props.
--
Added file: https://bugs.python.org/file47342/changes.diff
___
Python tracker
<https://bugs.python.org/issue32
Decorater added the comment:
If needed I could help upload the updated project files here for this issue.
--
nosy: +Decorater
___
Python tracker
<https://bugs.python.org/issue32
Decorater added the comment:
Oddly AppVeyor failed on VS2017 but build works on my end though.
--
___
Python tracker
<https://bugs.python.org/issue32326>
___
___
Decorater added the comment:
Alright made the backport PR on it. Not sure if it needs an news entry or if it
is trivial though.
--
___
Python tracker
<https://bugs.python.org/issue32
Change by Decorater :
--
keywords: +patch
pull_requests: +4837
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32326>
___
___
Python-
New submission from Decorater :
It seems that 1 thing that bites me is that there is no section on the
embedding docs about limitations to using frozen modules in them.
So lets say for example your program has this like in the main function on an
embedded python:
```c
PyRun_SimpleString
Change by Decorater :
--
keywords: +patch
pull_requests: +4804
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32353>
___
___
Python-
Change by Decorater :
--
components: +Build, Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
___
Python tracker
<https://bugs.python.org/issue32
New submission from Decorater :
It seems that When I uninstalled an older version of the Windows 10 SDK to make
more disk space to update Visual Studio that now python 3.6 will not compile. I
am not sure if Python 3.7 on master currently has this issue or not though I
still have not tested it
Decorater added the comment:
After thinking about this, maybe a better aproach is to somehow make freeze
when used on windows somehow read pyconfig.h
--
___
Python tracker
<https://bugs.python.org/issue32
Decorater added the comment:
python ..\externals\cpython\Tools\freeze\freeze.py pyeimport.py
Error: needed directory E:\python360\lib\python3.6\config-3.6 not found
Use ``..\externals\cpython\Tools\freeze\freeze.py -h'' for help
Seems like freeze works now with no traceback. However
Decorater added the comment:
I have found an temporary fix for now after reading that abiflags is posix only.
--
___
Python tracker
<https://bugs.python.org/issue32
Change by Decorater :
--
keywords: +patch
pull_requests: +4628
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32217>
___
___
Python-
Change by Decorater :
--
versions: +Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue32217>
___
___
Python-bugs-list mailing list
Unsub
Decorater added the comment:
Seems that freeze.py was not updated since 3.6.0b2 and also fails like this in
master as well. (specifically commit 10108a7b9affa61719a1dc1863edb2bdb3402fd1)
was last edit to the file in both the 3.6 and the master branch.
Could it be that ``sys.abiflags`` was
Decorater added the comment:
It seems to also give the same traceback when using the build from the latest
commit on branch 3.6 as well as 3.6.0 when using the freeze.py from the clone
as well (The way I tested it was manually patching the binaries in my my 3.6
install
New submission from Decorater :
It seems on my system installed python 3.6.0 when invoking python 3.6.3's
freeze.py it seems to fail with this traceback:
python ..\externals\cpython\Tools\freeze\freeze.py pyeimport.py
Traceback (most recent call last):
File "..\externals\cpython\To
Decorater added the comment:
Alright, just wanted to make sure because I did not want to have something
break when loading up the entire standard library from an zip file with it.
--
___
Python tracker
<https://bugs.python.org/issue25
Change by Decorater :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue29885>
___
___
Python-bugs-list
Change by Decorater :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue30396>
___
___
Python-bugs-list
Decorater added the comment:
If it was me I would store the warning registry in an error log or something in
the current directory that ran python itself. (maybe something like ``[main
script name].log``? This way it generates the warnings like usual and does not
eat up memory. And then the
Change by Decorater :
--
components: +Interpreter Core, Library (Lib)
___
Python tracker
<https://bugs.python.org/issue32106>
___
___
Python-bugs-list mailin
New submission from Decorater :
After looking in the folder Python sysmodule.c is in there instead of in
Modules. I am wondering if it has any reason to be in that folder instead of in
Modules/* with the other builtin modules in python.
If not I think it is best to move it so that way it is
Change by Decorater :
--
keywords: +patch
pull_requests: +4428
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32105>
___
___
Python-
Decorater added the comment:
Will see whhat I can do.
--
nosy: +Decorater
___
Python tracker
<https://bugs.python.org/issue32105>
___
___
Python-bugs-list mailin
Decorater added the comment:
Ah, I see now.
--
___
Python tracker
<https://bugs.python.org/issue32086>
___
___
Python-bugs-list mailing list
Unsubscribe:
Decorater added the comment:
For me, it looks like Py_DecodeLocal() is still safe (according to python 3.6.3
unless anything changed in it).
--
nosy: +Decorater
___
Python tracker
<https://bugs.python.org/issue32
Decorater added the comment:
Interesting, on 3.6.3 on my embedded program it seems to work just fine.
Did anything change in it since then?
https://github.com/AraHaan/Els_kom_new/blob/master/PC/komextract_new.c
--
nosy: +Decorater
___
Python
Decorater added the comment:
So, after reviewing this it started to make me rethink about the zipimport.py
file.
So my question is how would that file work if it is an pyc file in python37.zip
or something just to zipimport other modules? There is got to be some sort of
low level api that
Decorater added the comment:
Well since issue25711 might be for 3.7 and newer I guess this patch might
actually be for 3.6.4 or something then. And then the rewrite would take over
on 3.7 and newer depending on if the rewrite makes it in to 3.7.
--
versions: +Python 3.6 -Python 3.7
Decorater added the comment:
That is true, but Well, I am using this in a project of mine currently where it
loads up encrypted scripts from a zip file. However I must have the import hook
itself be in an C extension and subclass the current zipimporter. However
knowing a rewrite for it is
Change by Decorater :
--
assignee: -> docs@python
components: +Build, Documentation
nosy: +docs@python
___
Python tracker
<https://bugs.python.org/issu
Decorater added the comment:
After looking in the smelly tool it seems that now I got to rename the _Type to
ZipImporter to have the ``Py`` prefix. Since this will be a probable breaking
change this might not be a good idea on backporting to 3.6
Change by Decorater :
--
versions: -Python 3.6
___
Python tracker
<https://bugs.python.org/issue32075>
___
___
Python-bugs-list mailing list
Unsubscribe:
Decorater added the comment:
Seems that now this is detected as an smelly symbol:
./python Tools/scripts/smelly.py
+ nm -p libpython3.7dm.a
Ignored symbol types: b, d, r, t
Smelly symbol: ZipImporter_Type (type: D)
ERROR: Found 1 smelly symbols!
make: *** [smelly] Error 1
I think I need to
Change by Decorater :
--
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue32075>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Decorater :
--
keywords: +patch
pull_requests: +4402
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32075>
___
___
Python-
New submission from Decorater :
I would like to make an C extension module which basically would have the
ZipImporter type defined in the ``zipimport.c`` which defines most things
related to ZipImporter to be public so that way one can set it to ``.tp_base``
on their C extension.
That should
Decorater added the comment:
Closing this in favor of https://www.python.org/dev/peps/pep-0539/.
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/i
Changes by Decorater :
--
type: -> crash
___
Python tracker
<https://bugs.python.org/issue31413>
___
___
Python-bugs-list mailing list
Unsubscrib
New submission from Decorater:
E:\TinyURL\app\Release>tinyurl
Fatal Python error: only 'import site' is supported in ._pth file
Current thread 0x161c (most recent call first):
The above Happens when I try to use the ._pth file to automatically call
.main()
However it prints
Changes by Decorater :
--
versions: +Python 3.7
___
Python tracker
<http://bugs.python.org/issue27523>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Decorater :
--
pull_requests: +2437
___
Python tracker
<http://bugs.python.org/issue27523>
___
___
Python-bugs-list mailing list
Unsubscribe:
Decorater added the comment:
Reopened as I found where to actually silence it.
--
status: closed -> open
___
Python tracker
<http://bugs.python.org/issu
Decorater added the comment:
turns out it was crashing because I forgot to add in Py_Initialize.
--
___
Python tracker
<http://bugs.python.org/issue30574>
___
___
Decorater added the comment:
I found where the crash was at. It was at my call to PyRun_SimpleString.
Something in the string caused it to crash.
--
___
Python tracker
<http://bugs.python.org/issue30
Decorater added the comment:
E:\Users\Elsword\Documents\GitHub\TinyURL\app>call "E:\Program Files (x86)\Micro
soft Visual Studio 14.0\Common7\Tools\VsDevCmd.bat"
E:\Users\Elsword\Documents\GitHub\TinyURL\app>cd "E:\Users\Elsword\Documents\Git
Hub\TinyURL\app\"
E:\User
Decorater added the comment:
Wait a minute, I think it is because the 32 and 64 bit python36.lib files are
in the path environment variable so that might be the reason for the crash.
--
___
Python tracker
<http://bugs.python.org/issue30
Decorater added the comment:
I am compiling and linking to 32 bit python based on the folder I entered for
the lib file. Unless the lib file in the lib folder is somehow for the 64 bit
one.
--
___
Python tracker
<http://bugs.python.org/issue30
Decorater added the comment:
Well looks like with cl.exe it is still crashing.
--
___
Python tracker
<http://bugs.python.org/issue30574>
___
___
Python-bugs-list m
Decorater added the comment:
hmm, maybe it was because I was compiling it inside of the VS2015 IDE in an
project file and not with cl.exe directly.
--
___
Python tracker
<http://bugs.python.org/issue30
Decorater added the comment:
Well the example I linked if I compile it and try to run it it instantly
crashes with no explainable reason. I am using the same compiler used to build
the core too and the normal interpreter works just fine with the code I am
trying to embed. So it seems to
New submission from Decorater:
According to this example at
https://docs.python.org/3/extending/embedding.html#very-high-level-embedding
you can use something similar on embedding the interpreter.
However for some reason it can crash on Windows and probably some other
platforms no matter
Changes by Decorater :
Added file: http://bugs.python.org/file46878/suggested_change.diff
___
Python tracker
<http://bugs.python.org/issue30409>
___
___
Python-bugs-list m
New submission from Decorater:
The way the documentation currently is set up there is no way to know what
these functions in the C API actually do or what all the parameters are to call
it unless someone source dives into python. Because of this I think making an C
API page or a section for
Changes by Decorater :
--
status: closed -> open
___
Python tracker
<http://bugs.python.org/issue30390>
___
___
Python-bugs-list mailing list
Unsubscrib
Decorater added the comment:
Still it does look the functions lited in the second comment are undocumented.
https://docs.python.org/3/search.html?q=PyClassMethodDescr_Type
https://docs.python.org/3/search.html?q=PyClassMethod_New&check_keywords=yes&area=default
However on the last fu
Decorater added the comment:
Hmm seems that when looking at the exports in python36.dll that the following
functions seem to not be documented as far as I seen:
PyClassMethodDescr_Type
PyClassMethod_New
PyClassMethod_Type
There might be more functions dealing with classes that are not
New submission from Decorater:
On the C API, it tells how to make modules, functions, variables, and other
things, but what about classes?
Like for example if you wanted to make a class with all of the methods having
to use direct C Code which would then be converted to PyObject *'
Decorater added the comment:
I think the patch that haypo added should help take care of the warning. It
does however only warned when building for 64 bit.
--
___
Python tracker
<http://bugs.python.org/issue29
Changes by Decorater :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue29252>
___
Decorater added the comment:
Alright moved the bug part to http://bugs.python.org/issue30222.
--
___
Python tracker
<http://bugs.python.org/issue30214>
___
___
New submission from Decorater:
Basically running make_zip like this:
".\PCbuild\amd64\python.exe" ".\Tools\msi\make_zip.py" -a x64 -o
".\python36-x86-x64"
Cuases make_zip mess up where none of the libs\*.lib, nor any of the assemblies
are copied. And is repr
Decorater added the comment:
Alright renamed it.
--
___
Python tracker
<http://bugs.python.org/issue30214>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Decorater :
--
title: make_zip.py lacks command a few line options and has a bug. ->
make_zip.py lacks command a few line options.
___
Python tracker
<http://bugs.python.org/issu
New submission from Decorater:
make_zip.py does not offer the options to include tests with the tkinner stuff
when making the full distributions immediately after building python using MSVC.
Basically running makezip like this:
".\PCbuild\amd64\python.exe" ".\Tools\msi\make_zi
Decorater added the comment:
Oh
--
title: Added missing archive programs and close option to Windows docs. ->
Added missing archive programs.
___
Python tracker
<http://bugs.python.org/issu
Changes by Decorater :
--
title: Added missing things to Windows docs. -> Added missing archive programs
and close option to Windows docs.
___
Python tracker
<http://bugs.python.org/issu
Changes by Decorater :
--
pull_requests: +1349
___
Python tracker
<http://bugs.python.org/issue30122>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Decorater :
--
pull_requests: +1348
___
Python tracker
<http://bugs.python.org/issue30122>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Decorater :
--
pull_requests: +1347
___
Python tracker
<http://bugs.python.org/issue30122>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Decorater:
I realized the Windows docs lacked some information so I added it. I will try
to create an cherry pick for 3.6 and 3.6 as well. Also if desired I could also
see if it can be applied to the 2.7 branch as well.
--
assignee: docs@python
components
New submission from Decorater:
I noticed that there is no ways to convert local times to GMT if I realize that
some other object (sometimes from a server) is using GMT and they happen to be
ahead of my current time. As such it would be great if one can convert their
current time that can be
Decorater added the comment:
an url preview of the bug itself
https://travis-ci.org/AraHaan/datetime_diff/jobs/213944228
--
___
Python tracker
<http://bugs.python.org/issue29
Decorater added the comment:
Yeah, I could. I did just realize that there is a bug in it though that
sometimes if it is like 58 seconds into a minute and you sleep for 15 that the
code then thinks an entire minute elapsed when it has not. I need to think of a
way to bypass that bug first. I
Decorater added the comment:
I plan to also have it to where if it is the last unit in the thing that it
appends an and to the end as well.
--
___
Python tracker
<http://bugs.python.org/issue29
Decorater added the comment:
Alright I revised it a bit locally too
>>> import datetime
>>> datetime.datetime_diff(datetime.datetime(2017, 1, 31),
>>> datetime.datetime(2017, 1, 31))
''
>>> datetime.datetime_diff(datetime.datetime(2016, 12, 31,
Decorater added the comment:
Oh, I just realized I forgot to add other if's to each block in case certain
parts was 0 but others was not. I also realized I tried to do
datetime.datetime.new instead of datetime.datetime.now on the
Decorater added the comment:
I have people who would use it and there are use cases for it as well. Also it
works perfectly fine the other one I added to it's docstring is an example
datetime object of my very own discord account from when I creat
New submission from Decorater:
The datetime_diff function compares two datetime objects and returns the time
since the prior datetime objects (based on the current datetime object) in a
what that is readable by humans.
This is useful when one might need to compare two datetime objects
Changes by Decorater :
--
pull_requests: +663
___
Python tracker
<http://bugs.python.org/issue29866>
___
___
Python-bugs-list mailing list
Unsubscribe:
Decorater added the comment:
tbh, I would rather have it default for all python files installed for all
users to go in ``%SystemDrive%\Python{major}{minor}`` on windows and then work
with then the environment variables like currently so that way none of the
python dll's are outside of
Decorater added the comment:
hmm, I see. Well I was looking for an way to actually be able to use decorators
made in the same class to be able to somehow pass in the same instance as well.
Currently the only way to use class decorators is for them to be static (which
would not allow using or
New submission from Decorater:
So, many people rely on Decorators in class that accepts an instance of itself
like so:
class ExampleClass:
"""Example class with an example decorator that cannot be used."""
def __init__(self):
self.list_of_ite
Decorater added the comment:
And yeah that is why I stuck most of the changes in here under __CYGWIN__
macros for now until I know otherwise that all of the changes will not break
other platforms.
--
___
Python tracker
<http://bugs.python.
Decorater added the comment:
hmm maybe if TSS is available on all platforms maybe python could use that
instead of TLS so that way I would not have to have a lot of __CYGWIN__'s all
over the place. However I am not sure if all of the OS's that are on the
buildbot for python support
Decorater added the comment:
Also I just realized my Cygwin updated to 2.7.0 as well.
--
___
Python tracker
<http://bugs.python.org/issue29718>
___
___
Python-bug
Decorater added the comment:
Well then I am thinking about figuring out how to make an batch file under
tools/buildbot to target cygwin building in windows. tbh windows 7 or newer on
cygwin is fine with me. It is just that I need to figure out how to make it
invoke Cygwin.bat and yet also
Decorater added the comment:
I use cygwin to test things that I write in python to see if they work under
linux without having to boot up into an linux VM to find out as it would be too
slow to even do that with the computer I have. And besides cygwin makes all of
this faster. The version of
Decorater added the comment:
For now I stuck it under cygwin only but it could easily move out to not only
cygwin if desired.
--
___
Python tracker
<http://bugs.python.org/issue29
Decorater added the comment:
Yes, it is because of the fact in Cygwin it will cause an compile Error when
ints are involved forcing other methods to be put in place.
--
___
Python tracker
<http://bugs.python.org/issue29
Changes by Decorater :
Added file: http://bugs.python.org/file46698/cygwin_build.patch
___
Python tracker
<http://bugs.python.org/issue29718>
___
___
Python-bugs-list m
Changes by Decorater :
Removed file: http://bugs.python.org/file46697/cygwin_build.patch
___
Python tracker
<http://bugs.python.org/issue29718>
___
___
Python-bugs-list m
Changes by Decorater :
--
pull_requests: +373
___
Python tracker
<http://bugs.python.org/issue29718>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Decorater :
--
keywords: +patch
Added file: http://bugs.python.org/file46697/cygwin_build.patch
___
Python tracker
<http://bugs.python.org/issue29
New submission from Decorater:
Cygwin had an issue with building and installing python after it was
configured. The main issue was the TLS key stuff which would make python fail
to fully build or work correctly. This issue contains a patch for cygwin
specifically to make it compile and work
Decorater added the comment:
In 3.6 and 3.7 The Same Error is back on line 960 with gcc 6.3.0 on cygwin64.
This issue is not entirely fixed even with the absolute latest commits.
$ make
gcc -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-pro
totypes-std=c99 -Wextra
1 - 100 of 209 matches
Mail list logo
