[issue36064] docs: urllib.request.Request not accepting iterables data type

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

I would propose closing it since docs were made improved and if type checking 
needs to be enforced then it can be discussed in the linked open issues that 
have patches.

--

___
Python tracker 

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

[issue36464] Python 2.7 build install fails intermittently with -j on MacOS

[Paul Smith]

Paul Smith  added the comment:

I've tried on both MacOS 10.12 and 10.14.  I'm using GNU make 4.2.1 (built 
myself, not the one that comes with Xcode).

I have not tried Python3 builds.  I agree with you that -jN probably has little 
impact on the install step, but the build infrastructure I'm using simply 
provides it by default on both the build and install steps.

All my builds are completely from scratch and scripted; I start with a tarball, 
unpack it, then do an out-of-tree builds that run configure, then run "make" 
then "make install".

Note that these commands are _themselves_ invoked from a makefile the controls 
the build so they are recursive make invocations and the parent make was 
started with -j8 or so, causing the child makes to inherit that parallelism.

I doubt much of that is relevant though.  Here's the issue:

  install: commoninstall ...

  commoninstall: ... altbininstall ... libainstall ...

  altbininstall: $(BUILDPYTHON)

  libainstall: all python-config

So, these two targets altbininstall and libainstall are both prerequisites of 
commoninstall, which is a prerequisite of install.

Since there's no dependency relationship between altbininstall and libainstall, 
make is free to run them both at the same time if you invoke it with 
parallelism enabled.

Both of these targets try to create directories; altbininstall uses:

@for i in $(BINDIR) $(LIBDIR); \
do \
if test ! -d $(DESTDIR)$$i; then \
echo "Creating directory $$i"; \
$(INSTALL) -d -m $(DIRMODE) $(DESTDIR)$$i; \
elsetrue; \
fi; \
done

and libainstall uses:

@for i in $(LIBDIR) $(LIBP) $(LIBPL) $(LIBPC); \
do \
if test ! -d $(DESTDIR)$$i; then \
echo "Creating directory $$i"; \
$(INSTALL) -d -m $(DIRMODE) $(DESTDIR)$$i; \
elsetrue; \
fi; \
done

You can see that both try to create the directory $(LIBDIR).  They do test for 
directory existence first but that's not sufficient when running in parallel: 
if they are running at the same time they might both test at the same time and 
succeed, then one will create the directory first.

Because the rule uses install -d, which (unlike mkdir -p for example) will fail 
if the directory already exists, you have a potential problem here.

If the Python 3 makefile has similar target constructs it will have the same 
issue.

--

___
Python tracker 

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

[issue27181] Add geometric mean to `statistics` module

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> On the basis that something is better than nothing, go ahead.
> We can discuss accuracy and speed issues later.

Thanks.  I'll put together a PR for your consideration.

--

___
Python tracker 

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

Re: Levenberg-Marquardt non-linear least-squares fitting in Python [follow-on]

[William Ray Wing via Python-list]

Below I’ve included the code I ran, reasonably (I think) commented.  Note the 
reference to the example.  The data actually came from a pandas data frame that 
was in turn filled from a 100 MB data file that included lots of other data not 
needed for this, which was a curve fit to a calibration run.

Bill

PS:  If you want, I can probably still find a couple of the plots of the raw 
data and fitted result.
-
import numpy as np, matplotlib.pyplot as plt
#
#  Inverted exponential that axymptotically approaches "a" as x gets large
#
def func2fit(x,a,b,c):
return a - b * np.exp(-c * x)

# Curve fitting below from: 
https://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.curve_fit.html
  
from scipy.optimize import curve_fit
def fit(xdata, ydata, run_num):
ll = len(xdata)
#
#  The next four lines shift and scale the data so that the curve fit routine 
can
#  do its work without needing to use 8 or 16-byte precision. After fitting, we
#  will scale everything back.
#
ltemp = [ydata[i] - ydata[0] for i in range(ll)]
ytemp = [ltemp[i] * .001 for i in range(ll)]
ltemp = [xdata[i] - xdata[0] for i in range(ll)]
xtemp = [ltemp[i] * .001 for i in range(ll)]
#
#  popt is a list of the three optimized fittine parameters [a, b, c]
#  we are interested in the value of a.
#  cov is the 3 x 3 covariance matrix, the standard deviation (error) of the 
fit is
#  the square root of the diagonal.
#
popt,cov = curve_fit(func2fit, xtemp, ytemp)
#
#  Here is what the fitted line looks like for plotting
#
fitted = [popt[0] - popt[1] * np.exp(-popt[2] * xtemp[i]) for i in 
range(ll)]
#
#  And now plot the results to check the fit
#
fig1, ax1 = plt.subplots()
plt.title('Normalized Data ' + str(run_num))
color_dic = {0: "red", 1: "green", 2: "blue", 3: "red", 4: "green", 5: 
"blue"}
ax1.plot(xtemp, ytemp, marker = '.', linestyle  = 'none', color = 
color_dic[run_num])
ax1.plot(xtemp, fitted, linestyle = '-', color = color_dic[run_num])
plt.savefig('Normalized ' + str(run_num))
perr = np.sqrt(np.diag(cov))
return popt, cov, xdata[0], ydata[0], fitted, perr[0] 

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

[issue36064] docs: urllib.request.Request not accepting iterables data type

[Carol Willing]

Carol Willing  added the comment:

I've merged Julien Palard's doc PR. Is this sufficient to close this issue?

--

___
Python tracker 

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

[issue36064] docs: urllib.request.Request not accepting iterables data type

[Carol Willing]

Carol Willing  added the comment:


New changeset 9e30fbac019d9c0a31d444a711e845c7e883caf5 by Carol Willing (Julien 
Palard) in branch 'master':
bpo-36064: Clarify allowed data types for urllib.request.Request. (GH-11990)
https://github.com/python/cpython/commit/9e30fbac019d9c0a31d444a711e845c7e883caf5


--
nosy: +willingc

___
Python tracker 

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

[issue36466] Adding a way to strip annotations from compiled bytecode

[cary]

New submission from cary :

Similar to how `-OO` currently strips docstrings from compiled bytecode, it 
would be nice if there were a way to strip annotations as well to further 
compact the bytecode.

Attached is my initial attempt. From some simple manual testing, Python with 
this patch applied will generate the same bytecode (verified with `marshal` and 
`dis`) for two files with the same logic, but with annotations manually removed 
from one of them.

This will probably need some new flag/optimization level rather than relying on 
`-OO` (as it would be a breaking change).

Open to initial reviews of the patch and idea in general, and suggestions on 
how to best thread the option through to the module.

--
components: Interpreter Core
files: strip_annotations.patch
keywords: patch
messages: 339091
nosy: cary
priority: normal
severity: normal
status: open
title: Adding a way to strip annotations from compiled bytecode
type: enhancement
Added file: https://bugs.python.org/file48237/strip_annotations.patch

___
Python tracker 

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

[issue33043] Add a 'Contributing to Docs' link at the bottom of docs.python.org

[Carol Willing]

Carol Willing  added the comment:


New changeset 081158e3ba20dfa95d09cd652a44e271b95eb14c by Carol Willing (Susan 
Su) in branch 'master':
bpo-33043: Add a Contributing to Docs link and Update the Found a Bug Page 
(#12006)
https://github.com/python/cpython/commit/081158e3ba20dfa95d09cd652a44e271b95eb14c


--

___
Python tracker 

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

[issue33043] Add a 'Contributing to Docs' link at the bottom of docs.python.org

[Carol Willing]

Change by Carol Willing :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

[issue36464] Python 2.7 build install fails intermittently with -j on MacOS

[Carol Willing]

Carol Willing  added the comment:

Thanks @madscientist for filing an issue. It would be helpful to have a bit 
more detail on what specific MacOS version you are building on as well as the 
specific commands that you are executing.

Does this also happen if you run `make clean` before running a build?

--
nosy: +willingc

___
Python tracker 

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

[issue18697] Unify arguments names in Unicode object C API documentation

[Rune Tynan]

Rune Tynan  added the comment:

I have some interest in making a fix for this. From discussion, I'm thinking 
that, barring names that already have clear meaning (EG, left/right for things 
with two parameters):
- PyObject* that is unknown type remains `obj`
- PyObject* with unicode string is `unicode`
- const char*, const Py_UNICODE*, and const wchar* becomes `str`
- const char, const Py_UNICODE, and const wchar become `ch`

Those seem to be the intersect of most common and most descriptive names 
already seen.

--

___
Python tracker 

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

[issue36260] Cpython/Lib vulnerability found and request a patch submission

[KunYu Chen]

KunYu Chen  added the comment:

Thank you for the responses.

I agree with Christian Heimes.

It's indeed better to improve the documentation rather than directly implement 
the heuristic.

--

___
Python tracker 

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

[issue36464] Python 2.7 build install fails intermittently with -j on MacOS

[Ned Deily]

Ned Deily  added the comment:

What version of macOS do you see this with and to what kind of macOS file 
system are you installing?  Also, is the failure seem with Python 3.x installs? 
 For what it's worth, I've never seen this and I do a *lot* of make installs on 
macOS but, while I usually do a make -j3 for the build steps, I rarely use -j 
on install steps as I doubt it has much positive effect there.

--
nosy: +ned.deily

___
Python tracker 

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

[issue27181] Add geometric mean to `statistics` module

[STINNER Victor]

Change by STINNER Victor :


--
nosy:  -vstinner

___
Python tracker 

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

[issue36462] CVE-2019-9674 : zip bomb vulnerability in Lib/zipfile.py

[JUN-WEI SONG]

JUN-WEI SONG  added the comment:

Thanks to the python community, both of these issues are the same.

I also think it's a good thing to make related documentation to reduce this 
type of problem rather than implementing it on a low-level zipfile module. 
Perhaps we can customize such a requirement through a pip package.

--

___
Python tracker 

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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Terry Reedy]

On 3/28/2019 12:29 PM, Alexey Muranov wrote:

On jeu., Mar 28, 2019 at 5:00 PM, python-list-requ...@python.org wrote:


So my opinion is that lambda expressions should only be used within 
larger expressions and never directly bound.



It would be however more convenient to be able to write instead just

    f(x) = x*x


Given my view above, this is, standing alone, strictly an abbreviation 
of the equivalent def statement.  I am presuming that a proper 
implementation would result in f.__name__ == 'f'.




No, after some thought, i think it should be an abbreviation of "f = 
lambda x: x*x", f.__name__ would still be ''.


Throwing the name away is foolish.  Testing functions is another 
situation in which function names are needed for proper report.  I wrote 
and use a test function something like the following, simplified and 
adapted for use with unittest:


def ftest(func, io_pairs):
errors = []
for input, expected in io_pairs:
actual = func(input)
if actual != expected:
errors.append(
f"Func: {func.__name__}, input: {input}, "
f"expected: {expected}, actual: {actual}.")
return errors if errors else None

(Then "self.assertNone(ftest(func, io_pairs))" will test all pairs and 
list at least part of the error list.)


If all the names were '', not very useful.  (The workaround 
would be to require the caller to know a name and pass it separately, 
without mis-typing.)


for unittest, a


But i see your point about never assigning lambdas directly, it makes 
sense.  But sometimes i do assign short lambdas directly to variable.


Is the convenience and (very low) frequency of applicability worth the 
inconvenience of confusing the meaning of '=' and complicating the 
implementation?



I do not see any conflicts with the existing syntax.


It heavily conflicts with existing syntax.  The current meaning of
  target_expression = object_expression
is
1. Evaluate object_expression in the existing namespace to an object, 
prior to any new bindings and independent of the target_expression.
2. Evaluate target_expression in the existing namespace to one or more 
targets.

3. Bind object to target or iterate target to bind to multiple targets.


I do not thick so.  In "x = 42" the variable x is not evaluated.

All examples of the proposed syntax i can think of are currently 
illegal, so i suppose there is no conflicts. (I would appreciate a 
counterexample, if any.)


You are talking about syntax conflicts, I am talking about semantic 
conflict, which is important for human understanding.



Thanks for the reference to PEP 8, this is indeed an argument against.


The situation in which assigning lambda expressions is more tempting is 
when assigning to attributes or dicts.


def double(x): return x*x
C.double = double
d['double'] = double
versus

C.double = lambda x: x*x
d['double'] = lambda x: x*x

For attributes, "def C.double(x): return x*x" has been proposed but not 
accepted.



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

[issue36260] Cpython/Lib vulnerability found and request a patch submission

[JUN-WEI SONG]

JUN-WEI SONG  added the comment:

Thank you python community, these two issues are indeed the same problem.

I also think that it is good to make a related document to reduce such problems.

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

___
Python tracker 

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

[issue27181] Add geometric mean to `statistics` module

[Steven D'Aprano]

Steven D'Aprano  added the comment:

> In the spirit of "perfect is the enemy of good", would it be 
> reasonable to start with a simple, fast implementation using 
> exp-mean-log?  Then if someone wants to make it more accurate later, 
> they can do so.

I think that is a reasonable idea. On the basis that something is better 
than nothing, go ahead. We can discuss accuracy and speed issues later.

Getting some tricky cases down for reference:

# older (removed) implementation
py> geometric_mean([7]*2)
7.0
py> geometric_mean([7]*15)
7.0

# Raymond's newer (faster) implementation
py> exp(fmean(map(log, [7]*2)))
6.999
py> exp(fmean(map(log, [7]*15)))
6.999

py> geometric_mean([3,27])
9.0
py> geometric_mean([3,27]*5)
9.0

py> exp(fmean(map(log, [3,27])))
9.002
py> exp(fmean(map(log, [3,27]*5)))
8.998

py> x = 2.5e15
py> geometric_mean([x]*100)
2500.0
py> exp(fmean(map(log, [x]*100)))
2499.5

On the other hand, sometimes rounding errors work in our favour:

py> geometric_mean([1e50, 1e-50])  # people might expect 1.0
0.9998
py> 1e-50 == 1/(1e50)  # even though they aren't quite inverses
False

py> exp(fmean(map(log, [1e50, 1e-50])))
1.0

--

___
Python tracker 

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

[issue36465] No longer enable Py_TRACE_REFS by default in debug build

[STINNER Victor]

STINNER Victor  added the comment:

PR 12615 changes Py_DEBUG to no longer imply Py_TRACE_REFS. IMHO it's a more 
reasonable approach.

I'm not sure if it's enough to magically get exactly the same ABI than Python 
built in release mode.

--

___
Python tracker 

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

[issue36465] No longer enable Py_TRACE_REFS by default in debug build

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +12551

___
Python tracker 

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

[issue36465] No longer enable Py_TRACE_REFS by default in debug build

[STINNER Victor]

STINNER Victor  added the comment:

> Another more radical idea is to completely remove Py_TRACE_REFS special build.

I wrote PR 12614 to implement this idea. I wrote it to see which code depends 
on it:

commit 63509498761a0e7f72585a8cd7df325ea2abd1b2 (HEAD -> remove_trace_refs, 
origin/remove_trace_refs)
Author: Victor Stinner 
Date:   Thu Mar 28 23:26:58 2019 +0100

WIP: bpo-36465: Remove Py_TRACE_REFS special build

Remove _ob_prev and _ob_next fields of PyObject when Python is
compiled in debug mode to make debug ABI closer to the release ABI.

Remove:

* sys.getobjects()
* PYTHONDUMPREFS environment variable
* _PyCoreConfig.dump_refs
* PyObject._ob_prev and PyObject._ob_next fields
* _PyObject_HEAD_EXTRA and _PyObject_EXTRA_INIT macros
* _Py_AddToAllObjects()
* _Py_PrintReferenceAddresses()
* _Py_PrintReferences()
* _Py_ForgetReference(op) is replaced with _Py_INC_TPFREES(op)

I never used PYTHONDUMPREFS. I just tried in Python 3.7: Python does crash with 
this option... so this option doesn't sound popuplar. Otherwise, many users 
would complain.

$ PYTHONDUMPREFS=1 python3.7-dbg -c pass
...
0x7f7eae14aa90 [1] 'Thread-local dummy'
0x7f7eae19b448 [1] (, )
0x7f7eae14aa30 [1] {'__doc__': 'Thread-local dummy'}
0x7f7eae1356d8 [1] (,)
0x7d0940 [2] 
0x7f7eae120d58 [1] Segmentation fault (core dumped)

I never used sys.getobjects() neither, but I can imagine that someone might 
want to use for very specific needs. So maybe it's safer to not immediately 
remove the feature. At least, a deprecation period would be needed.

I suggest to reject PR 12614 and not remove Py_TRACE_REFS.

--

___
Python tracker 

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

[issue36465] No longer enable Py_TRACE_REFS by default in debug build

[STINNER Victor]

Change by STINNER Victor :


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

___
Python tracker 

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

[issue36465] No longer enable Py_TRACE_REFS by default in debug build

[STINNER Victor]

New submission from STINNER Victor :

When Python is built in debug mode, PyObject gets 2 new fields: _ob_prev and 
_ob_next. These fields change the offset of following fields in the PyObject 
structure and so breaks the ABI.

I propose to modify the debug build (Py_DEBUG) to not imply Py_TRACE_REFS 
anymore. Antoine Pitrou proposed this idea when the C API was discussed to get 
a stable ABI.

Another more radical idea is to completely remove Py_TRACE_REFS special build.

--
components: Build
messages: 339079
nosy: pitrou, vstinner
priority: normal
severity: normal
status: open
title: No longer enable Py_TRACE_REFS by default in debug build
versions: Python 3.8

___
Python tracker 

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

Re: Getting file extensions [linux fs]

[Cameron Simpson]

On 28Mar2019 01:12, Paulo da Silva  wrote:

Às 23:09 de 27/03/19, Cameron Simpson escreveu:

On 27Mar2019 21:49, Paulo da Silva  wrote:

...

The filefrag manual entry says it works by calling one of 2 ioctls. You
can do that from Python with the ioctl() function in the standard fcntl
module. I haven't tried to do this, but the results should be basicly as
fast as filefrag itself.

You'll need to decode the result the ioctl returns of course.


Thanks Cameron, I'll take a look at that.


Oh, just tangential to this.

If you were doing this ad hoc, yes calling the filefrag executable is 
very expensive. But if you are always doing a large batch of filenames 
invoking:


 filefrag lots of filenames here ...

and reading from its output can be very effective, because the expense 
of the executable is amortized over all the files - the per file cost is 
much reduced. And it saves you working out how to use the ioctls from 
Python :-)


You'll learn more from going the ioctl route though, and it gives you 
complete control if you need it.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

[issue36464] Python 2.7 build install fails intermittently with -j on MacOS

[Paul Smith]

New submission from Paul Smith :

Maybe no one cares anymore, but I've discovered that if I run make with -j the 
installation sometimes fails with this error:

install: mkdir /Users/build/.../dist/python/x86_64-darwin/lib: File exists

I believe it's because the targets altbininstall and libainstall as well as 
$(DESTSHARED) ($(BINLIBDEST)/lib-dynload) all contain a for loop which tries to 
create $(LIBDIR).  The makefile uses the install -d command to create 
directories and this command will fail if the directory already exists.

I haven't investigated the full dependency chain but at least two of the above 
targets don't have a relationship that forces make to avoid running them both 
at the same time.

Maybe a better solution would be to create a separate target like 
make-directories or something that creates all the directories and have the 
other targets depend on that one target.  Or something.

As it is, my MacOS builds fail about 1 in 5 times or similar.

Interestingly my Linux builds never fail.  Not sure if install works 
differently on Linux, or the timing is just different there.

--
components: Build
messages: 339078
nosy: madscientist
priority: normal
severity: normal
status: open
title: Python 2.7 build install fails intermittently with -j on MacOS
type: behavior
versions: Python 2.7

___
Python tracker 

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

[issue30427] isinstance checks in os.path.normcase redundant with os.fspath

[miss-islington]

miss-islington  added the comment:


New changeset 74510e2a57f6d4b51ac1ab4f778cd7a4c54b541e by Miss Islington (bot) 
(Wolfgang Maier) in branch 'master':
bpo-30427: eliminate redundant type checks in os.path.normcase() (GH-1712)
https://github.com/python/cpython/commit/74510e2a57f6d4b51ac1ab4f778cd7a4c54b541e


--
nosy: +miss-islington

___
Python tracker 

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

Re: Handy utilities = Friday Filosofical Finking

[Test Bot]

+1

On Fri, Mar 29, 2019, 2:04 AM DL Neil 
wrote:

> How do you keep, use, and maintain those handy snippets, functions,
> classes... - units of code, which you employ over-and-over again?
>
>
> Having coded 'stuff' once, most of us will keep units of code,
> "utilities", which we expect will be useful in-future (DRY principle),
> eg functions to rename files, choose unique back-up/new fileNMs,
> accessing a DB, journalling (logging) start/stop msgs, building specs
> from YAML/JSON/XML/.ini config files (tongue~cheek), etc.
>
> Do you 'keep' these, or perhaps next time you need something you've
> 'done before' do you remember when/where a technique was last
> used/burrow into 'history'?
> (else, code it from scratch, all over again)
>
> How do you keep them updated, ie if add some new idea, better
> err-checking, re-factor - how to add these 'back' into previous places
> utility is used?
> (who wants more "technical debt", plus handling classic
> update/versioning issue)
>
> How do you keep these? eg special file/dir, within IDE, leave in app and
> 'remember', on paper, ... If the former, how do you access/import them
> from the various applications/systems?
> (Python's import rules and restrictions, change control/version control)
>
>
> Am interested to hear your tactics; to learn, compare, and contrast...
> --
> Regards,
> =dn
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue36366] Patcher stop method should be idempotent

[Brett Cannon]

Brett Cannon  added the comment:

Thanks, everyone!

--
nosy: +brett.cannon
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

[issue36366] Patcher stop method should be idempotent

[miss-islington]

miss-islington  added the comment:


New changeset 02b84cb1b4f5407309c81c8b1ae0397355d6e568 by Miss Islington (bot) 
(Xtreak) in branch 'master':
bpo-36366: Return None on stopping unstarted patch object (GH-12472)
https://github.com/python/cpython/commit/02b84cb1b4f5407309c81c8b1ae0397355d6e568


--
nosy: +miss-islington

___
Python tracker 

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

[issue36425] Add Simplified Chinese to the language switcher

[Julien Palard]

Change by Julien Palard :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

[issue36441] Cannot create venv with debug binaries installed

[Steve Dower]

Change by Steve Dower :


--
assignee:  -> steve.dower
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Chris Angelico]

On Fri, Mar 29, 2019 at 7:29 AM Alexey Muranov  wrote:
> My idea however was to have it as an exact synonyme of an assignment of
> a lambda. Assignment is an assignment, it should not modify the
> attributs of the value that is being assigned.

Assigning lambda functions to names generally shouldn't be done. Just
use def. You're asking for another way to do a bad thing that has a
better alternative.

There have periodically been proposals for the opposite, which would
take care of some of the alternatives:

def op["double"](x): return x * x

This kind of proposal has its own issues, but I think it has a much
better chance of being accepted than a way of creating and assigning
lambda functions.

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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Ian Kelly]

On Thu, Mar 28, 2019 at 2:30 PM Alexey Muranov 
wrote:
>
> On jeu., mars 28, 2019 at 8:57 PM, Terry Reedy  wrote:
> > Throwing the name away is foolish.  Testing functions is another
> > situation in which function names are needed for proper report.
>
> My idea however was to have it as an exact synonyme of an assignment of
> a lambda. Assignment is an assignment, it should not modify the
> attributs of the value that is being assigned.

There could perhaps be a special case for lambda expressions such that,
when they are directly assigned to a variable, Python would use the
variable name as the function name. I expect this could be accomplished by
a straightforward transformation of the AST, perhaps even by just replacing
the assignment with a def statement.

Since this could just as easily be applied to lambda though, I'm afraid it
doesn't offer much of a case for the "f(x)" syntactic sugar.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Alexey Muranov]

On jeu., mars 28, 2019 at 5:00 PM, python-list-requ...@python.org wrote:

So documentation of that syntax would 100% be required


Regarding documentation, i believe there would be 3 line to add:


() = 

is a syntactic sugar for

 = lambda : 


Alexey.


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

Handy utilities = Friday Filosofical Finking

[DL Neil]

How do you keep, use, and maintain those handy snippets, functions, 
classes... - units of code, which you employ over-and-over again?



Having coded 'stuff' once, most of us will keep units of code, 
"utilities", which we expect will be useful in-future (DRY principle), 
eg functions to rename files, choose unique back-up/new fileNMs, 
accessing a DB, journalling (logging) start/stop msgs, building specs 
from YAML/JSON/XML/.ini config files (tongue~cheek), etc.


Do you 'keep' these, or perhaps next time you need something you've 
'done before' do you remember when/where a technique was last 
used/burrow into 'history'?

(else, code it from scratch, all over again)

How do you keep them updated, ie if add some new idea, better 
err-checking, re-factor - how to add these 'back' into previous places 
utility is used?
(who wants more "technical debt", plus handling classic 
update/versioning issue)


How do you keep these? eg special file/dir, within IDE, leave in app and 
'remember', on paper, ... If the former, how do you access/import them 
from the various applications/systems?

(Python's import rules and restrictions, change control/version control)


Am interested to hear your tactics; to learn, compare, and contrast...
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Alexey Muranov]

On jeu., mars 28, 2019 at 8:57 PM, Terry Reedy  wrote:

On 3/28/2019 12:29 PM, Alexey Muranov wrote:
On jeu., Mar 28, 2019 at 5:00 PM, python-list-requ...@python.org 
wrote:


So my opinion is that lambda expressions should only be used within 
larger expressions and never directly bound.


It would be however more convenient to be able to write instead 
just


f(x) = x*x


Given my view above, this is, standing alone, strictly an 
abbreviation of the equivalent def statement.  I am presuming 
that a proper implementation would result in f.__name__ == 'f'.




No, after some thought, i think it should be an abbreviation of "f = 
lambda x: x*x", f.__name__ would still be ''.


Throwing the name away is foolish.  Testing functions is another 
situation in which function names are needed for proper report.


My idea however was to have it as an exact synonyme of an assignment of 
a lambda. Assignment is an assignment, it should not modify the 
attributs of the value that is being assigned.




But i see your point about never assigning lambdas directly, it 
makes sense.  But sometimes i do assign short lambdas directly to 
variable.


Is the convenience and (very low) frequency of applicability worth 
the inconvenience of confusing the meaning of '=' and 
complicating the implementation?



I do not see any conflicts with the existing syntax.


It heavily conflicts with existing syntax.  The current meaning of
  target_expression = object_expression
is
1. Evaluate object_expression in the existing namespace to an 
object, prior to any new bindings and independent of the 
target_expression.
2. Evaluate target_expression in the existing namespace to one or 
more targets.
3. Bind object to target or iterate target to bind to multiple 
targets.


I do not thick so.  In "x = 42" the variable x is not evaluated.

All examples of the proposed syntax i can think of are currently 
illegal, so i suppose there is no conflicts. (I would appreciate a 
counterexample, if any.)


You are talking about syntax conflicts, I am talking about semantic 
conflict, which is important for human understanding.


Thanks for the reference to PEP 8, this is indeed an argument 
against.


The situation in which assigning lambda expressions is more tempting 
is when assigning to attributes or dicts.


def double(x): return x*x
C.double = double
d['double'] = double
versus

C.double = lambda x: x*x
d['double'] = lambda x: x*x


These are some of examples i had in mind as well:

   C.double(x) = x*x
   d['double'](x) = x*x

Alexey.


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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Alexey Muranov]

On jeu., mars 28, 2019 at 8:57 PM, Terry Reedy  wrote:


But i see your point about never assigning lambdas directly, it 
makes sense.  But sometimes i do assign short lambdas directly to 
variable.


Is the convenience and (very low) frequency of applicability worth 
the inconvenience of confusing the meaning of '=' and 
complicating the implementation?



I do not see any conflicts with the existing syntax.


It heavily conflicts with existing syntax.  The current meaning of
  target_expression = object_expression
is
1. Evaluate object_expression in the existing namespace to an 
object, prior to any new bindings and independent of the 
target_expression.
2. Evaluate target_expression in the existing namespace to one or 
more targets.
3. Bind object to target or iterate target to bind to multiple 
targets.


I do not thick so.  In "x = 42" the variable x is not evaluated.

All examples of the proposed syntax i can think of are currently 
illegal, so i suppose there is no conflicts. (I would appreciate a 
counterexample, if any.)


You are talking about syntax conflicts, I am talking about semantic 
conflict, which is important for human understanding.


I believe there is no semantic conflict either, or could you be more 
specific?


Alexey.


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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Alexey Muranov]

On jeu., mars 28, 2019 at 5:00 PM, python-list-requ...@python.org wrote:

On 2019-03-27 10:42 a.m., Paul Moore wrote:
 On Wed, 27 Mar 2019 at 12:27, Alexey Muranov 
 wrote:
 On mer., mars 27, 2019 at 10:10 AM, Paul Moore 


 wrote:

 On Wed, 27 Mar 2019 at 08:25, Alexey Muranov
  wrote:

  Whey you need a simple function in Python, there is a choice
 between a
  normal function declaration and an assignment of a anonymous
 function
  (defined by a lambda-expression) to a variable:

  def f(x): return x*x

  or

  f = lambda x: x*x

  It would be however more convenient to be able to write instead 
just


  f(x) = x*x
 Why? Is saving a few characters really that helpful? So much so 
that
 it's worth adding a *third* method of defining functions, which 
would

 need documenting, adding to training materials, etc, etc?

 Because i think i would prefer to write it this way.

 That's not likely to be sufficient reason for changing a language
 that's used by literally millions of people.


 (Almost no new documentation or tutorials would be needed IMHO.)
 Documentation would be needed to explain how the new construct 
worked,

 for people who either wanted to use it or encountered it in other
 people's code. While it may be obvious to you how it works, it 
likely
 won't be to others, and there will probably be edge cases you 
haven't

 considered that others will find and ask about.


For what it's worth, if I encountered "f(x) = x * x" in code, my first
thought would be that Python somehow added a way to return an 
assignable
reference from a function, rather than this being an anonymous 
function

declaration.

So documentation of that syntax would 100% be required

Alex



The thing to the right of the assignment symbol represents a value (an 
object), but the thing to the left does not represent a value, it 
represents a place for a value.


What would an "assignable reference" mean? Say, variable "x" holds an 
"assignable reference", what can be done next?


Alexey.


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

[issue36463] python37.dll crashing 0xc000041d

[Savagery]

New submission from Savagery :

Faulting application name: python.exe, version: 3.7.2150.1013, time stamp: 
0x5c200a7f
Faulting module name: python37.dll, version: 3.7.2150.1013, time stamp: 
0x5c200a56
Exception code: 0xc41d
Fault offset: 0x0011517b
Faulting process ID: 0x4c2c
Faulting application start time: 0x01d4e5999a14e806
Faulting application path: 
C:\Users\lwilson\AppData\Local\Programs\Python\Python37-32\python.exe
Faulting module path: 
C:\Users\lwilson\AppData\Local\Programs\Python\Python37-32\python37.dll
Report ID: 511d75b6-febe-4358-a886-ccfd89b1747e
Faulting package full name: 
Faulting package-relative application ID: 

--

I'm using ctypes to create a UI in my code, python is crashing silently. 
Managed to get some info from windows event log. Have no clue why - seems the 
more static controls I create, the higher the likelihood of this happening is.

--
components: Windows
files: debug.rar
messages: 339074
nosy: Savagery, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: python37.dll crashing 0xc41d
type: crash
versions: Python 3.7
Added file: https://bugs.python.org/file48236/debug.rar

___
Python tracker 

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

[issue35941] ssl.enum_certificates() regression

[miss-islington]

miss-islington  added the comment:


New changeset e9868c5416731f5ca5378a1d36e4b020c349291c by Miss Islington (bot) 
in branch '3.7':
bpo-35941: Fix ssl certificate enumeration for windows (GH-12486)
https://github.com/python/cpython/commit/e9868c5416731f5ca5378a1d36e4b020c349291c


--
nosy: +miss-islington

___
Python tracker 

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

[issue36460] Add AMP MIME type support

[Daniel Black]

Daniel Black  added the comment:

That's exactly what I meant: use, but in a way that cares how that data is
structured. Thanks for the pointer, I'll take a look.

--

___
Python tracker 

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

[issue35941] ssl.enum_certificates() regression

[Christian Heimes]

Change by Christian Heimes :


--
pull_requests: +12549

___
Python tracker 

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

[issue34498] Python 3.7 breaks on singledispatch_function.register(pseudo_type), which Python 3.6 accepted

[Michael Selik]

Michael Selik  added the comment:

+1 for this use case. Until it's resolved, perhaps there should be a note in 
the singledispatch docs that types from the ``typing`` module should not be 
used?

--
nosy: +selik

___
Python tracker 

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

[issue36460] Add AMP MIME type support

[R. David Murray]

R. David Murray  added the comment:

Not sure what you mean by "depend on that structure".  A quick grep
shows the only stdlib modules that use mimetimes are urllib and
http.server.

Backward compatibility will of course be a significant issue here.

--

___
Python tracker 

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

[issue35941] ssl.enum_certificates() regression

[Christian Heimes]

Christian Heimes  added the comment:

By the way, OpenSSL ignores duplicate certificates. There is no need to filter 
out duplicate entries. However it is more efficient to filter them out early, 
because OpenSSL filters after parsing the ASN.1 structure.

--

___
Python tracker 

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

[issue35941] ssl.enum_certificates() regression

[Christian Heimes]

Christian Heimes  added the comment:

Steve, why did you add the list_contains() check? Does the new code return one 
certificate multiple times? I'm worried that the performance of check is rather 
slow. IMHO it would be more efficient to use a set here.

--

___
Python tracker 

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

[issue36425] Add Simplified Chinese to the language switcher

[miss-islington]

miss-islington  added the comment:


New changeset 1d9f1a0c9690f4e53003dc5e625a2867715c828a by Miss Islington (bot) 
in branch '3.7':
bpo-36425: Add Simplified Chinese to the language switcher (GH-12537)
https://github.com/python/cpython/commit/1d9f1a0c9690f4e53003dc5e625a2867715c828a


--
nosy: +miss-islington

___
Python tracker 

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

Jinja and non-ASCII characters (was Re: Prepare accented characters for HTML)

[Chris Angelico]

On Fri, Mar 29, 2019 at 4:10 AM Tony van der Hoff  wrote:
>
> This'll probably work:
>
> accent-test/accent-test.py:
> #
> #!/usr/bin/env python3
>
> import os
> from jinja2 import Environment, FileSystemLoader
>
> PATH = os.path.dirname(os.path.abspath(__file__))
> TEMPLATE_ENVIRONMENT = Environment(
> autoescape=False,
> loader=FileSystemLoader(os.path.join(PATH, 'templates')),
> trim_blocks=False)
>
>
> def render_template(template_filename, context):
> return
> TEMPLATE_ENVIRONMENT.get_template(template_filename).render(context)
>
>
> def create_index_html():
>
> # put the list into a dictionary for rendering
> context = {
> 'title': "accent-test",
> 'french': 'année',
> 'french1': 'anne',
>   }
>
> # render the template to html
> print ("Content-type: text/html\n\n")
> print (render_template('accent-test.jnj', context))
>
> def main():
> create_index_html()
>
> 
>
> if __name__ == "__main__":
> main()
> #
>
> accent-test/templates/accent-test.jnj:
>
> #
> 
> 
>   
> 
> {{title}}
>   
>   
> 
>   {{title}}
> {#
>   {{french}}
> #}
>   {{french1}}
> 
>   
> 
>
> #

Well, I just tried this, and it worked fine (even after uncommenting
the 'french' line). Gave me this output:

Content-type: text/html




  

accent-test
  
  

  accent-test
  année
  anne

  


You have a python3 shebang, but are you definitely running this under Python 3?

Here's a much more minimal example. Can you see if this also fails for you?

import sys
from jinja2 import Template
print(Template("French: {{french}}").render({"french": "année"}))
print(sys.version)

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

Re: Prepare accented characters for HTML

[Peter Otten]

Tony van der Hoff wrote:

> On 28/03/2019 16:58, Chris Angelico wrote:
>> On Fri, Mar 29, 2019 at 3:47 AM Tony van der Hoff 
>> wrote:
>>>
>>> On 28/03/2019 15:09, Peter Otten wrote:
 Tony van der Hoff wrote:

> On 28/03/2019 12:46, Jon Ribbens wrote:
>> On 2019-03-28, Tony van der Hoff  wrote:
>>> Thanks, Chris. The problem is not with the browser, but Jinja
>>> crashes. Probably a bug, but I'm too wedded to that engine to change
>>> now. I'll raise it on the Jinja bug site.
>>
>> It'll almost certainly be a mistake in the way you're using Jinja.
>> I can't believe nobody's used non-ASCII characters in Jinja before.
>>
>
> I'm open to suggestions.

 You have to describe the "crash". If you can provide a small script to
 reproduce it that would be best. For demonstration purposes feed the
 renderer a constant string instead of reading from the db.

 You should also tell us which version of Python and Jinja you are
 using.


>>> OK,The crash is evidenced by an empty web page being generated,
>>> containing just 
>>> elements, with no content. No error messages nor exceptions.
>>>
>>> I.m using python3.5.3 and jinja 2.10.
>>>
>>> I have placed a sample script with a jnj template at
>>> 
https://drive.google.com/drive/folders/1rM5F46wRqHYn0VBXUhSl8DkNcwsp2u8b?usp=sharing
>>>
>>> The template contains a commented-out line, which when uncommented shows
>>> the alleged bug.
>> 
>> I can't see any of the code. Are you able to share it in a more
>> code-friendly way, such as linking to a repository on GitHub, GitLab,
>> BitBucket, SourceForge, or something else (probably with a capital
>> letter in the middle of the name, for consistency)?
>> 
>> Or, even better: create a short enough example that you can just
>> include it in the body of your post?
>> 
> 
> I hate Google!
> 
> This'll probably work:
> 
> accent-test/accent-test.py:
> #
> #!/usr/bin/env python3
> 
> import os
> from jinja2 import Environment, FileSystemLoader
> 
> PATH = os.path.dirname(os.path.abspath(__file__))
> TEMPLATE_ENVIRONMENT = Environment(
> autoescape=False,
> loader=FileSystemLoader(os.path.join(PATH, 'templates')),
> trim_blocks=False)
> 
> 
> def render_template(template_filename, context):
> return
> TEMPLATE_ENVIRONMENT.get_template(template_filename).render(context)
> 
> 
> def create_index_html():
> 
> # put the list into a dictionary for rendering
> context = {
> 'title': "accent-test",
> 'french': 'année',
> 'french1': 'anne',
>   }
> 
> # render the template to html
> print ("Content-type: text/html\n\n")
> print (render_template('accent-test.jnj', context))
> 
> def main():
> create_index_html()
> 
> 
> 
> if __name__ == "__main__":
> main()
> #
> 
> accent-test/templates/accent-test.jnj:
> 
> #
> 
> 
>   
> 
> {{title}}
>   
>   
> 
>   {{title}}
> {#
>   {{french}}
> #}
>   {{french1}}
> 
>   
> 
> 
> #
> 

When I run this from the command line it doesn't raise an exception. Are you 
absolutely sure the script is executed with Python 3?

If it were Python 2 you'd need to specify the encoding and ensure that the 
non-ascii text is unicode (u"..." rather than "...")

#!/usr/bin/env python
# -*- coding: utf-8 -*-

...

 'french': u'année',

...

If that's not the problem maybe there is something useful in the server 
logs?

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

[issue35941] ssl.enum_certificates() regression

[miss-islington]

Change by miss-islington :


--
pull_requests: +12548

___
Python tracker 

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

[issue35941] ssl.enum_certificates() regression

[Steve Dower]

Steve Dower  added the comment:


New changeset d93fbbf88e4abdd24a0a55e3ddf85b8420c62052 by Steve Dower 
(kctherookie) in branch 'master':
bpo-35941: Fix ssl certificate enumeration for windows (GH-12486)
https://github.com/python/cpython/commit/d93fbbf88e4abdd24a0a55e3ddf85b8420c62052


--

___
Python tracker 

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

[issue36451] Docs zh-cn roots error in nav bar

[Julien Palard]

Julien Palard  added the comment:

There was no link to zh-cn because they did not reached the completion needed 
for the link to appear.

Now it's done, so per https://bugs.python.org/issue36425 this will be resolved.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Add Simplified Chinese to the language switcher

___
Python tracker 

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

[issue28718] '*' matches entire path in fnmatch

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue36460] Add AMP MIME type support

[Daniel Black]

Daniel Black  added the comment:

I see! Okay... I'll consider a solution to the filetype portion of the
mimetypes map. Do you happen to know which other modules may depend on that
structure?

Yes... the lightning is silly.

Dan Black
http://dan.black
917-873-3970

On Thu, Mar 28, 2019 at 10:55 AM R. David Murray 
wrote:

>
> R. David Murray  added the comment:
>
> That link should do for our purposes here.
>
> The fact that it is an 'x-' mimetype means it has not been approved at
> any level.  There might be an in progress application to the mimetype
> registry, but if so the web site doesn't mention it anywhere obvious.
>
> I'm not sure about the filetype problem, but I'm guessing amp isn't the
> only mimetype that will have this issue going forward, so we probably need
> to come up with a solution.  You don't need support from the mimetypes
> module to create or manipulate emails using the content-type, though,
> so it isn't a blocker on that side.
>
> That lightning thing is *seriously* hokey :(
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue36462] CVE-2019-9674 : zip bomb vulnerability in Lib/zipfile.py

[Brett Cannon]

Brett Cannon  added the comment:

You can also leave a comment in the other issue saying there's more details
in the closed duplicate.

On Thu, Mar 28, 2019 at 9:54 AM Karthikeyan Singaravelan <
rep...@bugs.python.org> wrote:

>
> Karthikeyan Singaravelan  added the comment:
>
> I would request closing the other one as duplicate and opening this since
> this contains the actual report or perhaps the report could be copied to
> issue36260. Since Serhiy suggested closing this as not a bug I will leave
> it to him on resolution of the other issue too.
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue36425] Add Simplified Chinese to the language switcher

[miss-islington]

Change by miss-islington :


--
pull_requests: +12547

___
Python tracker 

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

Re: Prepare accented characters for HTML

[Tony van der Hoff]

On 28/03/2019 16:58, Chris Angelico wrote:
> On Fri, Mar 29, 2019 at 3:47 AM Tony van der Hoff  
> wrote:
>>
>> On 28/03/2019 15:09, Peter Otten wrote:
>>> Tony van der Hoff wrote:
>>>
 On 28/03/2019 12:46, Jon Ribbens wrote:
> On 2019-03-28, Tony van der Hoff  wrote:
>> Thanks, Chris. The problem is not with the browser, but Jinja crashes.
>> Probably a bug, but I'm too wedded to that engine to change now. I'll
>> raise it on the Jinja bug site.
>
> It'll almost certainly be a mistake in the way you're using Jinja.
> I can't believe nobody's used non-ASCII characters in Jinja before.
>

 I'm open to suggestions.
>>>
>>> You have to describe the "crash". If you can provide a small script to
>>> reproduce it that would be best. For demonstration purposes feed the
>>> renderer a constant string instead of reading from the db.
>>>
>>> You should also tell us which version of Python and Jinja you are using.
>>>
>>>
>> OK,The crash is evidenced by an empty web page being generated,
>> containing just 
>> elements, with no content. No error messages nor exceptions.
>>
>> I.m using python3.5.3 and jinja 2.10.
>>
>> I have placed a sample script with a jnj template at
>> https://drive.google.com/drive/folders/1rM5F46wRqHYn0VBXUhSl8DkNcwsp2u8b?usp=sharing
>>
>> The template contains a commented-out line, which when uncommented shows
>> the alleged bug.
> 
> I can't see any of the code. Are you able to share it in a more
> code-friendly way, such as linking to a repository on GitHub, GitLab,
> BitBucket, SourceForge, or something else (probably with a capital
> letter in the middle of the name, for consistency)?
> 
> Or, even better: create a short enough example that you can just
> include it in the body of your post?
> 

I hate Google!

This'll probably work:

accent-test/accent-test.py:
#
#!/usr/bin/env python3

import os
from jinja2 import Environment, FileSystemLoader

PATH = os.path.dirname(os.path.abspath(__file__))
TEMPLATE_ENVIRONMENT = Environment(
autoescape=False,
loader=FileSystemLoader(os.path.join(PATH, 'templates')),
trim_blocks=False)


def render_template(template_filename, context):
return
TEMPLATE_ENVIRONMENT.get_template(template_filename).render(context)


def create_index_html():

# put the list into a dictionary for rendering
context = {
'title': "accent-test",
'french': 'année',
'french1': 'anne',
  }

# render the template to html
print ("Content-type: text/html\n\n")
print (render_template('accent-test.jnj', context))

def main():
create_index_html()



if __name__ == "__main__":
main()
#

accent-test/templates/accent-test.jnj:

#


  

{{title}}
  
  

  {{title}}
{#
  {{french}}
#}
  {{french1}}

  


#

-- 
Tony van der Hoff| mailto:t...@vanderhoff.org
Buckinghamshire, England |
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue36260] Cpython/Lib vulnerability found and request a patch submission

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

All these are simple one-liners:

len(zf.infolist())
sum(zi.compress_size for zi in zf.infolist())
sum(zi.file_size for zi in zf.infolist())

--
nosy: +serhiy.storchaka

___
Python tracker 

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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Ian Kelly]

On Wed, Mar 27, 2019 at 3:13 AM Paul Moore  wrote:
>
> On Wed, 27 Mar 2019 at 08:25, Alexey Muranov 
wrote:
> >
> > Whey you need a simple function in Python, there is a choice between a
> > normal function declaration and an assignment of a anonymous function
> > (defined by a lambda-expression) to a variable:
> >
> > def f(x): return x*x
> >
> > or
> >
> > f = lambda x: x*x
> >
> > It would be however more convenient to be able to write instead just
> >
> > f(x) = x*x
>
> Why? Is saving a few characters really that helpful? So much so that
> it's worth adding a *third* method of defining functions, which would
> need documenting, adding to training materials, etc, etc?

Well, it does seem a bit silly to have more ways of formatting strings than
of defining functions. We have four of the former, so clearly we need to
address this by adding two more of the latter.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Prepare accented characters for HTML

[Chris Angelico]

On Fri, Mar 29, 2019 at 3:47 AM Tony van der Hoff  wrote:
>
> On 28/03/2019 15:09, Peter Otten wrote:
> > Tony van der Hoff wrote:
> >
> >> On 28/03/2019 12:46, Jon Ribbens wrote:
> >>> On 2019-03-28, Tony van der Hoff  wrote:
>  Thanks, Chris. The problem is not with the browser, but Jinja crashes.
>  Probably a bug, but I'm too wedded to that engine to change now. I'll
>  raise it on the Jinja bug site.
> >>>
> >>> It'll almost certainly be a mistake in the way you're using Jinja.
> >>> I can't believe nobody's used non-ASCII characters in Jinja before.
> >>>
> >>
> >> I'm open to suggestions.
> >
> > You have to describe the "crash". If you can provide a small script to
> > reproduce it that would be best. For demonstration purposes feed the
> > renderer a constant string instead of reading from the db.
> >
> > You should also tell us which version of Python and Jinja you are using.
> >
> >
> OK,The crash is evidenced by an empty web page being generated,
> containing just 
> elements, with no content. No error messages nor exceptions.
>
> I.m using python3.5.3 and jinja 2.10.
>
> I have placed a sample script with a jnj template at
> https://drive.google.com/drive/folders/1rM5F46wRqHYn0VBXUhSl8DkNcwsp2u8b?usp=sharing
>
> The template contains a commented-out line, which when uncommented shows
> the alleged bug.

I can't see any of the code. Are you able to share it in a more
code-friendly way, such as linking to a repository on GitHub, GitLab,
BitBucket, SourceForge, or something else (probably with a capital
letter in the middle of the name, for consistency)?

Or, even better: create a short enough example that you can just
include it in the body of your post?

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

[issue36260] Cpython/Lib vulnerability found and request a patch submission

[Christian Heimes]

Christian Heimes  added the comment:

Issue #36462 contains more information. The reporter claims that the zipfile 
module is inherent insecure because it does not provide any heuristics to make 
zipbomb attacks harder.

I'm -1 to implement such a heuristic. The zipfile module is a low level module 
and should not limit extraction by defaykt. Instead we should improve 
documentation and maybe implement some method that simplifies detection of 
zipbomb attacks. I'm thinking about a method that returns total count of files, 
total compressed size and total uncompressed size.

--
nosy: +christian.heimes

___
Python tracker 

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

[issue36462] CVE-2019-9674 : zip bomb vulnerability in Lib/zipfile.py

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

I would request closing the other one as duplicate and opening this since this 
contains the actual report or perhaps the report could be copied to issue36260. 
Since Serhiy suggested closing this as not a bug I will leave it to him on 
resolution of the other issue too.

--

___
Python tracker 

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

[issue31904] Python should support VxWorks RTOS

[Christian Heimes]

Christian Heimes  added the comment:

I'm against implementing crypt on top of OpenSSL's DES_crypt. Please don't 
support the module at all instead of just supporting a completely broken 
implementation.

--
nosy: +christian.heimes

___
Python tracker 

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

Re: Prepare accented characters for HTML

[Tony van der Hoff]

On 28/03/2019 15:09, Peter Otten wrote:
> Tony van der Hoff wrote:
> 
>> On 28/03/2019 12:46, Jon Ribbens wrote:
>>> On 2019-03-28, Tony van der Hoff  wrote:
 Thanks, Chris. The problem is not with the browser, but Jinja crashes.
 Probably a bug, but I'm too wedded to that engine to change now. I'll
 raise it on the Jinja bug site.
>>>
>>> It'll almost certainly be a mistake in the way you're using Jinja.
>>> I can't believe nobody's used non-ASCII characters in Jinja before.
>>>
>>
>> I'm open to suggestions.
> 
> You have to describe the "crash". If you can provide a small script to 
> reproduce it that would be best. For demonstration purposes feed the 
> renderer a constant string instead of reading from the db.
> 
> You should also tell us which version of Python and Jinja you are using.
> 
> 
OK,The crash is evidenced by an empty web page being generated,
containing just 
elements, with no content. No error messages nor exceptions.

I.m using python3.5.3 and jinja 2.10.

I have placed a sample script with a jnj template at
https://drive.google.com/drive/folders/1rM5F46wRqHYn0VBXUhSl8DkNcwsp2u8b?usp=sharing

The template contains a commented-out line, which when uncommented shows
the alleged bug.

Good luck!
-- 
Tony van der Hoff| mailto:t...@vanderhoff.org
Buckinghamshire, England |
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue36462] CVE-2019-9674 : zip bomb vulnerability in Lib/zipfile.py

[Brett Cannon]

Brett Cannon  added the comment:

Closing as a duplicate of issue36260.

--
nosy: +brett.cannon
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Cpython/Lib vulnerability found and request a patch submission

___
Python tracker 

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

[issue36453] pkgutil.get_importer only return the first valid path_hook(importer)

[Brett Cannon]

Change by Brett Cannon :


--
nosy:  -brett.cannon

___
Python tracker 

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

[issue36453] pkgutil.get_importer only return the first valid path_hook(importer)

[Brett Cannon]

Change by Brett Cannon :


--
title: get_importer only return the first valid path_hook(importer) -> 
pkgutil.get_importer only return the first valid path_hook(importer)

___
Python tracker 

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

[issue36453] pkgutil.get_importer only return the first valid path_hook(importer)

[Brett Cannon]

Brett Cannon  added the comment:

To clarify, this is for pkgutil.

--
nosy: +brett.cannon

___
Python tracker 

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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Alexey Muranov]

On jeu., Mar 28, 2019 at 5:00 PM, python-list-requ...@python.org wrote:


So my opinion is that lambda expressions should only be used within 
larger expressions and never directly bound.



It would be however more convenient to be able to write instead just

f(x) = x*x


Given my view above, this is, standing alone, strictly an 
abbreviation of the equivalent def statement.  I am presuming that a 
proper implementation would result in f.__name__ == 'f'.




No, after some thought, i think it should be an abbreviation of "f = 
lambda x: x*x", f.__name__ would still be ''.


But i see your point about never assigning lambdas directly, it makes 
sense.  But sometimes i do assign short lambdas directly to variable.


Is the convenience and (very low) frequency of applicability worth 
the inconvenience of confusing the meaning of '=' and complicating 
the implementation?



I do not see any conflicts with the existing syntax.


It heavily conflicts with existing syntax.  The current meaning of
  target_expression = object_expression
is
1. Evaluate object_expression in the existing namespace to an object, 
prior to any new bindings and independent of the target_expression.
2. Evaluate target_expression in the existing namespace to one or 
more targets.
3. Bind object to target or iterate target to bind to multiple 
targets.


I do not thick so.  In "x = 42" the variable x is not evaluated.

All examples of the proposed syntax i can think of are currently 
illegal, so i suppose there is no conflicts. (I would appreciate a 
counterexample, if any.)


Thanks for the reference to PEP 8, this is indeed an argument against.

Alexey.



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

[issue36462] CVE-2019-9674 : zip bomb vulnerability in Lib/zipfile.py

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Going by CVE number and report is this a duplicate of issue36260 ?

--
nosy: +xtreak

___
Python tracker 

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

[issue35983] tp_dealloc trashcan shouldn't be called for subclasses

[Jeroen Demeyer]

Change by Jeroen Demeyer :


--
pull_requests: +12546

___
Python tracker 

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

[issue36462] CVE-2019-9674 : zip bomb vulnerability in Lib/zipfile.py

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I do not think that the library should limit the compression ratio. Large 
compression ratio is legit. For example, compressed file of size 1 GiB 
consisting of zeros has the compress ratio 1030 (and I suppose it is even 
larger if use bzip2 or lzma compressions).

If this is a problem for your program, your program should make a decision what 
ZIP files should be rejected.

I suggest to close this issue as "not a bug".

--

___
Python tracker 

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

Re: Levenberg-Marquardt non-linear least-squares fitting in Python

[Madhavan Bomidi]

Hi Bill,

Thanks for your suggestion. Where am I actually using the curve_fit in the 
defined function func2fit? Don't I need to initial assumption of a, b and c 
values so that optimized convergence occur with iteration of the function for 
the input data of x?

Look forward to your suggestions,
Madhavan
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue28718] '*' matches entire path in fnmatch

[Toon Verstraelen]

Toon Verstraelen  added the comment:

For consistency with the corresponding feature in the glob function since 
Python 3.5, I would suggest to add an extra optional argument 'recursive' 
instead of 'glob_asterisks'. With the default recursive=False, one gets the old 
behavior, with recursive=True, it can handle the '**' and '*' as in pywildcard.

I realize that with recursive=False, the behavior is not exactly consistent 
with glob, but  I'd still prefer the same name for the optional argument. It is 
the common terminology for this type of feature. See 
https://en.wikipedia.org/wiki/Matching_wildcards

--
nosy: +Toon Verstraelen

___
Python tracker 

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

[issue36462] CVE-2019-9674 : zip bomb vulnerability in Lib/zipfile.py

[Stéphane Wirtel]

Change by Stéphane Wirtel :


--
nosy: +serhiy.storchaka, twouters

___
Python tracker 

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

[issue36462] CVE-2019-9674 : zip bomb vulnerability in Lib/zipfile.py

[JUN-WEI SONG]

New submission from JUN-WEI SONG :

Dear Python Community, 

we found a python module vulnerability during these days and we got a CVE 
number, CVE-2019-9674 after reported it to cve.mitre.org.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9674


The reserved information of CVE-2019-9674 is shown below:

   [Description]

   Lib/zipfile.py in Python through 3.7.2 allows remote 
   attackers to cause a denial of service (resource consumption) 
   via a ZIP bomb.


   [Additional Information]

   The python zipfile library version 3.2, 3.3, 3.4, 3.5, 3.6, 
   3.7, 3.8. Allow attackers to cause a denial of service (disk 
   volume exhaustion) via a ZIP bomb.


   We have found python standard library zipfile doesn't have 
   ZIP bomb detection and protection. If the user uses zipfile 
   library to unzip a ZIP bomb file, this might cause a denial 
   of service of the localhost.


  [VulnerabilityType Other]

  Denial-of-Service



Our proposed solutions:


1.The compression ratio:

Compression ratio = Uncompressed file size / Compressed file size

Since ZIP bomb file has a higher compression ratio (1028) than 
normal ZIP file (1 to 3). Therefore, we calculate the compression 
ratio and set a threshold for the detection.

2.Nested zip file

There is a high chance that it is zip bomb if it is a nested zip 
file. 

3.By limiting resources such as CPU, memory, disk usage.


Unsolved issue

However, we have not yet determined the compression ratio. We 
temporarily set the compression ratio to 10, and if it exceeds, it 
may be a ZIP bomb.

It is likely that detection may misjudge nested compressed files. 
For example, under normal circumstances, compressed files are 
included in the zip file.


Our solution code：

"""For ratio"""

def _exam_ratio(self, threshold=10):
"""If the ratio exceeds threshold, it may be a ZIP Bomb."""
sum_file_size = sum([data.file_size for data in self.filelist])
sum_compress_size = sum([data.compress_size for data in self.filelist])
ratio = sum_file_size / sum_compress_size
if (ratio > threshold):
raise BadZipFile("Zip Bomb Detected")

"""For Nested zip file"""

if(members.filename.endswith(".zip")):
raise BadZipFile("Nested Zip File Detected")


Thanks!

--
components: Library (Lib)
messages: 339053
nosy: krnick
priority: normal
severity: normal
status: open
title: CVE-2019-9674 : zip bomb vulnerability in Lib/zipfile.py
type: security
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue36425] Add Simplified Chinese to the language switcher

[Ezio Melotti]

Change by Ezio Melotti :


--
nosy: +ezio.melotti

___
Python tracker 

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

[issue36425] Add Simplified Chinese to the language switcher

[Julien Palard]

Julien Palard  added the comment:


New changeset 45a5fdb91cee665161a8b1980bb4e6ccb999f58f by Julien Palard (zhsj) 
in branch 'master':
bpo-36425: Add Simplified Chinese to the language switcher (GH-12537)
https://github.com/python/cpython/commit/45a5fdb91cee665161a8b1980bb4e6ccb999f58f


--

___
Python tracker 

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

[issue36459] A possible double PyMem_FREE() due to tokenizer.c's tok_nextc()

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

Re: Prepare accented characters for HTML

[Peter Otten]

Tony van der Hoff wrote:

> On 28/03/2019 12:46, Jon Ribbens wrote:
>> On 2019-03-28, Tony van der Hoff  wrote:
>>> Thanks, Chris. The problem is not with the browser, but Jinja crashes.
>>> Probably a bug, but I'm too wedded to that engine to change now. I'll
>>> raise it on the Jinja bug site.
>> 
>> It'll almost certainly be a mistake in the way you're using Jinja.
>> I can't believe nobody's used non-ASCII characters in Jinja before.
>> 
> 
> I'm open to suggestions.

You have to describe the "crash". If you can provide a small script to 
reproduce it that would be best. For demonstration purposes feed the 
renderer a constant string instead of reading from the db.

You should also tell us which version of Python and Jinja you are using.


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

[issue36459] A possible double PyMem_FREE() due to tokenizer.c's tok_nextc()

[miss-islington]

miss-islington  added the comment:


New changeset 6fd3c852b15820480ad2ea83e7857615c4976304 by Miss Islington (bot) 
in branch '3.7':
bpo-36459: Fix a possible double PyMem_FREE() due to tokenizer.c's tok_nextc() 
(12601)
https://github.com/python/cpython/commit/6fd3c852b15820480ad2ea83e7857615c4976304


--

___
Python tracker 

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

Re: Prepare accented characters for HTML

[Tony van der Hoff]

On 28/03/2019 12:46, Jon Ribbens wrote:
> On 2019-03-28, Tony van der Hoff  wrote:
>> Thanks, Chris. The problem is not with the browser, but Jinja crashes.
>> Probably a bug, but I'm too wedded to that engine to change now. I'll
>> raise it on the Jinja bug site.
> 
> It'll almost certainly be a mistake in the way you're using Jinja.
> I can't believe nobody's used non-ASCII characters in Jinja before.
> 

I'm open to suggestions.

-- 
Tony van der Hoff| mailto:t...@vanderhoff.org
Buckinghamshire, England |
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue36460] Add AMP MIME type support

[R. David Murray]

R. David Murray  added the comment:

That link should do for our purposes here.

The fact that it is an 'x-' mimetype means it has not been approved at
any level.  There might be an in progress application to the mimetype
registry, but if so the web site doesn't mention it anywhere obvious.

I'm not sure about the filetype problem, but I'm guessing amp isn't the
only mimetype that will have this issue going forward, so we probably need
to come up with a solution.  You don't need support from the mimetypes
module to create or manipulate emails using the content-type, though,
so it isn't a blocker on that side.

That lightning thing is *seriously* hokey :(

--

___
Python tracker 

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

Re: Levenberg-Marquardt non-linear least-squares fitting in Python

[William Ray Wing via Python-list]

> On Mar 28, 2019, at 7:54 AM, Madhavan Bomidi  wrote:
> 
> Hi,
> 
> I have x and y variables data arrays. These two variables are assumed to be 
> related as y = A * exp(x/B). Now, I wanted to use Levenberg-Marquardt 
> non-linear least-squares fitting to find A and B for the best fit of the 
> data. Can anyone suggest me how I can proceed with the same. My intention is 
> to obtain A and B for best fit.
> 

Have you looked at the non-linear least-squares solutions in scicpy?
Specifically, a system I’ve had to solve several times in the past uses it and 
it works quite well.

from scipy.optimize import curve_fit

def func2fit(x,a,b,c):
return a - b * np.exp(-c * x)

Bill

> Look forward to your suggestions and sample code as an example.
> 
> Thanks and regards,
> Madhavan
> -- 
> https://mail.python.org/mailman/listinfo/python-list

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

[issue36459] A possible double PyMem_FREE() due to tokenizer.c's tok_nextc()

[miss-islington]

miss-islington  added the comment:


New changeset dffe90ee0eaf77785ad3d4ad7fb3249430ed1cb9 by Miss Islington (bot) 
in branch '2.7':
bpo-36459: Fix a possible double PyMem_FREE() due to tokenizer.c's tok_nextc() 
(12601)
https://github.com/python/cpython/commit/dffe90ee0eaf77785ad3d4ad7fb3249430ed1cb9


--
nosy: +miss-islington

___
Python tracker 

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

[issue36387] Refactor getenvironment() in _winapi.c

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

[issue29515] socket module missing IPPROTO_IPV6, IPPROTO_IPV4 on Windows

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

Merged. I'm agnostic about backporting IPPROTO_IPV6 (or others) on < 3.8 so 
I'll leave it up to somebody else to decide/implement.

--
status: open -> pending
versions:  -Python 3.7

___
Python tracker 

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

[issue29515] socket module missing IPPROTO_IPV6, IPPROTO_IPV4 on Windows

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:


New changeset 3eca28c61363a03b81b9fb12775490d6e42d8ecf by Giampaolo Rodola in 
branch 'master':
bpo-29515: add missing socket.IPPROTO_* constants on Windows (GH-12183)
https://github.com/python/cpython/commit/3eca28c61363a03b81b9fb12775490d6e42d8ecf


--

___
Python tracker 

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

[issue36387] Refactor getenvironment() in _winapi.c

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 8abd7c7e37714ce0c42f871f81e52f14c155d1bd by Serhiy Storchaka in 
branch 'master':
bpo-36387: Refactor getenvironment() in _winapi.c. (GH-12482)
https://github.com/python/cpython/commit/8abd7c7e37714ce0c42f871f81e52f14c155d1bd


--

___
Python tracker 

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

[issue12445] dict view values objects are missing tp_richcmp and tp_as_number

[Inada Naoki]

Inada Naoki  added the comment:

I don't think we need it.  So I reject it.

If you believe many Pythonista really need it,
please start discussion on python-dev.

--

___
Python tracker 

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

[issue12445] dict view values objects are missing tp_richcmp and tp_as_number

[Julian Berman]

Julian Berman  added the comment:

Yes I know *why* it worked in Py2 -- still seems like an oversight :)

To me, comparing (multi)set-like is the only reasonable behavior there
which is what IIRC the patch did, but even without that, for a given dict,
d.values() != d.values().

So, it's not like comparison is currently unimplemented. It returns
answers, they just mostly make no sense. (And of course I know that what's
happening is we're falling back to an identity check)

On Thu, Mar 28, 2019, 09:51 Inada Naoki  wrote:

>
> Inada Naoki  added the comment:
>
> > Well, surely there are reasonable semantics :), because dict.values ==
> > dict.values was comparable before we had view objects.
>
> Because it was list.
>
> Now values view is not sequence-like or set-like.
>
> >>> {"a": "foo", "b": "bar"}.values() == {"a": "bar", "b": "foo"}.value()
> True if set-like.  False if sequence-like.
>
> If you want Python 2 behavior, you should convert it to list.
> Then you can use "sequence" semantics.
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue34826] io.BufferedReader crashes in 2.7 on memoryview attribute access

[Inada Naoki]

Change by Inada Naoki :


--
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> Crash when RawIOBase.write(b) evaluates b.format

___
Python tracker 

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

[issue36459] A possible double PyMem_FREE() due to tokenizer.c's tok_nextc()

[miss-islington]

Change by miss-islington :


--
pull_requests: +12545

___
Python tracker 

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

[issue36459] A possible double PyMem_FREE() due to tokenizer.c's tok_nextc()

[miss-islington]

Change by miss-islington :


--
pull_requests: +12544

___
Python tracker 

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

[issue36459] A possible double PyMem_FREE() due to tokenizer.c's tok_nextc()

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset cda139d1ded6708665b53e4ed32ccc1d2627e1da by Serhiy Storchaka 
(Zackery Spytz) in branch 'master':
bpo-36459: Fix a possible double PyMem_FREE() due to tokenizer.c's tok_nextc() 
(12601)
https://github.com/python/cpython/commit/cda139d1ded6708665b53e4ed32ccc1d2627e1da


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue31327] bug in dateutil\tz\tz.py

[Paul Ganssle]

Paul Ganssle  added the comment:

Can we change the title of this to something like, "Add example of 
platform-specific support for negative timestamps to the time documentation"?

That might be a bit wordy, but as it is now, this looks like it's reporting a 
bug in dateutil, which is not part of the standard library, which may be 
confusing people looking for something to solve.

As for the meat of the documentation change, I think we can adapt the wording 
from `datetime.fromtimestamp`, which actually has a very similar example called 
out: 
https://docs.python.org/3.7/library/datetime.html#datetime.datetime.fromtimestamp

> fromtimestamp() may raise OverflowError, if the timestamp is out of the range 
> of values supported by the platform C localtime() or gmtime() functions, and 
> OSError on localtime() or gmtime() failure. It’s common for this to be 
> restricted to years in 1970 through 2038.

--

___
Python tracker 

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

[issue12445] dict view values objects are missing tp_richcmp and tp_as_number

[Inada Naoki]

Inada Naoki  added the comment:

> Well, surely there are reasonable semantics :), because dict.values ==
> dict.values was comparable before we had view objects.

Because it was list.

Now values view is not sequence-like or set-like.

>>> {"a": "foo", "b": "bar"}.values() == {"a": "bar", "b": "foo"}.value()
True if set-like.  False if sequence-like.

If you want Python 2 behavior, you should convert it to list.
Then you can use "sequence" semantics.

--

___
Python tracker 

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

[issue12445] dict view values objects are missing tp_richcmp and tp_as_number

[Julian Berman]

Julian Berman  added the comment:

Well, surely there are reasonable semantics :), because dict.values ==
dict.values was comparable before we had view objects.

It's been awhile since I filed this, and still seems rather silly that:

 {"a": "foo"}.values() != {"a": "foo"}.values()
True

On Thu, Mar 28, 2019 at 9:18 AM Inada Naoki  wrote:

>
> Inada Naoki  added the comment:
>
> There is no reasonable semantics for values view.
> Keep it unimplemented.
>
> --
> nosy: +inada.naoki
> resolution:  -> rejected
> stage: patch review -> resolved
> status: open -> closed
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue32950] profiling python gc

[Christian Heimes]

Christian Heimes  added the comment:

Python supports dtrace / systemtap probes for gc, 
https://docs.python.org/3/howto/instrumentation.html?highlight=gc__start#c.gc__start

--
nosy: +christian.heimes

___
Python tracker 

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

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

[Paul Ganssle]

Paul Ganssle  added the comment:

>From the documentation ( 
>https://docs.python.org/3/library/datetime.html#datetime.datetime.fromtimestamp
> ):

> fromtimestamp() may raise OverflowError, if the timestamp is out of the range
> of values supported by the platform C localtime() or gmtime() functions, and
> OSError on localtime() or gmtime() failure. It’s common for this to be
> restricted to years in 1970 through 2038. Note that on non-POSIX systems that
> include leap seconds in their notion of a timestamp, leap seconds are ignored
> by fromtimestamp(), and then it’s possible to have two timestamps differing by
> a second that yield identical datetime objects. See also utcfromtimestamp().

So this is indeed the documented behavior. I agree that it would be good to 
unify the behavior across platforms if possible, but I think this would require 
us to have our own implementation of localtime() and/or gmtime().

That said, it might be possible to implement `fromtimestamp` with some 
equivalent of `datetime(1970, 1, 1) + timedelta(seconds=t)` on Windows when the 
value falls outside the accepted range. We'd probably need some better tests 
under different time zones to make sure that that would be acceptable.

I think it may be a good idea to change the targeted version to 3.8 or 3.9, 
because this is a change to the documented behavior of the function (albeit a 
desirable one that can probably be considered backwards compatible).

--

___
Python tracker 

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