[Python-Dev] Re: Declarative imports

[Dan Stromberg]

On Fri, Apr 8, 2022 at 1:26 AM Malthe  wrote:

> This is an idea which has been brought up before, sometimes introduced
> as "heresy". But an interesting twist has surfaced now which is
> typing.
>

What for?  To save a few keystrokes?

Can't some IDE's add the import for you?

Please don't drag Python in the direction of line noise.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/IOJ5J5OY4H2OLMXOGIX24EHGVT2VY5N4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

[Dan Stromberg]

On Sat, Mar 26, 2022 at 5:58 PM Ethan Furman  wrote:

> [apologies for the late post, just found this in my drafts folder]
>
> On 2/7/22 12:49 AM, Stéfane Fermigier wrote:
>
> > 3. Overall, I think the days where "battery included" was a positive
> argument are over
>
> I strongly disagree.  Being able to download something and immediately get
> something to work and see results is hugely
> rewarding; on the other hand, having to research, find, compare & contrast
> available third-party modules (especially for
> new-comers) can be extremely discouraging.
>

It might make sense to have CPython's release cadence decoupled from the
Standard Library's release cadence.  That is, maybe they should be separate
downloads.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/Y2FXUA643E7DJPKHPFGMI3IVC2PWTVKN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: How about using modern C++ in development of CPython ?

[Dan Stromberg]

On Fri, Apr 16, 2021 at 11:13 AM Christian Heimes 
wrote:

> On 16/04/2021 19.14, redrad...@gmail.com wrote:
> > My personal stop of contributing in CPython is that it is written in
> pure C !!
> > I wrote code in both: pure C and C++, but I like writing code in C++,
> because it simplifies things without losing perfomance
>
> There are plenty of Open Source projects that could use more capable C++
> developers. :)
>
> I'm not a fan of C++. It has its use cases, e.g. in UI. Python core
> isn't the best fit. AFAIK most core devs are not fluent in C++. Despite
> it's name, C++ is really a different language than C. It has a different
> ABI and stdlib than C, too. In my personal opinion C++ won't give us any
> net benefits. I'd much rather go for Rust than C++ to gain memory safety.
>
Agreed.

Rust would be much better than C++.  Rust actually brings something new and
interesting to the discussion.  C++ is "almost Java", but not as good.  The
Linux kernel tried C++, but backed away from it. But now it's adding Rust.

I've had the experience, in the past, of writing code in C++ only to find
that its intended users refused to use it /because/ it was in C++.  In
retrospect, I'm not entirely disappointed that they did - it steered me
toward sticking with bash and C, and getting more into Python.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/QJA7LHDJZSHYAPI6H6CQXD6GZ5HYIZF6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Having Sorted Containers in stdlib?

[Dan Stromberg]

On Tue, Nov 9, 2021 at 9:00 PM Steven D'Aprano  wrote:

> Sorting dicts has been discussed on the Python-Ideas mailing list, it is
> too hard and expensive to justify for the limited use-cases for it. If
> you want to sort a dict, you are best to sort the dict's keys, then
> create a new dict. Or possibly use a dedicated Sorted Mapping type like
> a red-black tree or similar.
>

There are several implementations of key-order sorted dicts available in
Python, and more than a few of them are well tested.  I am the maintainer
of one of them: https://pypi.org/project/treap/ which I ported from Java.
I also did a performance comparison among several of them a few years back.

Red-black trees are popular, perhaps especially among Java developers, but
I've never understood why.  They aren't the fastest.  Among traditional
tree-based key-sorted dicts, treaps are frequently fastest.

However, SortedDict is not uncommonly faster than treaps - I believe this
is because SortedDict is very good at maximizing locality of reference.
Traditional trees are almost always going to do an entire cache line hit
for every node in large trees, even if those nodes are "next to each other"
when sorted/traversed.  SortedDicts put keys that are nearly equal, in
nearly the same part of memory - so multiple values can be retrieved with a
single cache line hit.

Sorting a dict's keys inside a loop tends to give O(n^2) algorithms, and
sometimes even O(n^2 * logn).  This is not good.  A traditional tree should
give O(nlogn) algorithms under similar circumstances, and although my gut
is telling me SortedDict is similar the presentation linked below suggests
a different (though still better than sorting in a loop) runtime for
SortedDict.

It's true that key-sorted dicts are not all that common.  Their most common
use is probably for implementing finite caches - evictions can benefit from
ordered keys.  However, we already have functools.lru_cache.

Here's my most recent performance comparison:
https://stromberg.dnsalias.org/~strombrg/sorted-dictionary-comparison/Datastructure%20comparison.pdf

Here's a PyCon 2016 presentation about SortedContainers, that includes
SortedDict:
https://www.youtube.com/watch?v=7z2Ki44Vs4E

I think it would make sense to include at least one key-sorted dict in
CPython, and feel that SortedDict would not be a bad way to go.  Neither
would treap.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VNK4VPGA4LJH7RMR4LCCACEG2WNDBBFO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python multithreading without the GIL

[Dan Stromberg]

On Thu, Oct 7, 2021 at 9:10 PM Chris Angelico  wrote:

> Concurrency is *hard*. There's no getting around it, there's no
> sugar-coating it. There are concepts that simply have to be learned,
> and the failures can be extremely hard to track down. Instantiating an
> object on the wrong thread can crash GTK, but maybe not immediately.
> Failing to sleep in one thread results in other threads stalling. I
> don't think any of this is changed by different modes (with the
> exception of process-based parallelism, which fixes a lot of
> concurrency at the cost of explicit IPC), and the more work
> programmers want their code to do, the more likely that they'll run
> into this.
>

I'd like to encourage folks not to give up on looking for new, simpler
parallelism/concurrency formalisms.

They're out there - consider how well bash does with its parallelism in
pipelines.

The truly general ones may end up looking like Java, but I don't think they
have to be fully general to be useful.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/AVDCKO3OH2SPU54VWAY5AY4HEQWDMPRC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [slightly OT] cryptographically strong random.SystemRandom()

[Dan Stromberg]

On Mon, Jul 12, 2021 at 8:37 AM Steve Dower  wrote:

> On 7/12/2021 4:11 PM, Dan Stromberg wrote:
> > It looks like CPython could do better on Windows: SystemRandom (because
> > of os.urandom()) is good on Linux and mac, but on Windows they use the
> > CryptGenRandom deprecated API
> >
> > Supporting detail:
> >
> https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptgenrandom
> > <
> https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptgenrandom
> >
> >
> > Should I open an issue?
>
> Please do, but note that the API is only deprecated because it was not
> very extensible and the new API is much more comple... er... extensible.
>
> There's nothing wrong with the randomness from the function. It'll be
> using the new API under the covers. So this is an enhancement, not a
> security issue, and should only target 3.11.
>

I created https://bugs.python.org/issue44611 for this.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/C3QBAG3YHBJSJQ5MO32TFN6R6PBYKEKD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [slightly OT] cryptographically strong random.SystemRandom()

[Dan Stromberg]

On Fri, Jul 9, 2021 at 2:26 PM Tim Peters  wrote:

> [Ethan Furman]
> > A question [1] has arisen about the viability of `random.SystemRandom` in
> > Pythons before and after the secrets module was introduced
> > (3.5 I think) -- specifically
> >
> >  does it give independent and uniform discrete distribution for
> >  cryptographic purposes across CPython 3.x versions?
> >
> > ,,,
> > [1] https://stackoverflow.com/q/68319071/208880
>
> `secrets` is just a wrapper around `random.SystemRandom`, so the
> presence or absence of `secrets` doesn't matter.
>
> As to SystemRandom, all answers depend on the quality of the platform
> os.urandom(), which Python has no control over. See my answer here,
> and the comments on it:
>
>
> https://stackoverflow.com/questions/20936993/how-can-i-create-a-random-number-that-is-cryptographically-secure-in-python/20937265#20937265
>

It looks like CPython could do better on Windows: SystemRandom (because of
os.urandom()) is good on Linux and mac, but on Windows they use the
CryptGenRandom deprecated API

Supporting detail:
https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptgenrandom

Should I open an issue?
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/QP4EFVS66JMNXRADYKPW4YOI4PDCD6OU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Why list.sort() uses mergesort and not timsort?

[Dan Stromberg]

On Mon, Jun 7, 2021 at 11:20 AM Tim Peters  wrote:

> [Dan Stromberg ]
> > ...
> > Timsort added the innovation of making mergesort in-place, plus a little
> > (though already common) O(*n^2) sorting for small sublists.
>
> Actually, both were already very common in mergesorts. "timsort" is
> much more a work of engineering than of insight ;-) That is, it
> combined many pre-existing ideas, but pushed them hard, and got them
> to work smoothly together.
>
> The most novel part is "galloping" to vastly cut the number of
> comparisons needed in many real-world cases of partially ordered
> inputs.
>

Thanks Tim.

Python itself is a great language, but in part it was your good-natured and
well-reasoned posts about Python that got me into Python instead of OCaml.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7K6WWWAYEGRNQOW47DQE45FFNSKZSG7X/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Why list.sort() uses mergesort and not timsort?

[Dan Stromberg]

On Sun, Jun 6, 2021 at 2:46 AM Marco Sulla 
wrote:

> As title. Is it faster for inplace sorting, or simply the
> implementation of list.sort() was done before the implementation of
> timsort?
>

As you already know, timsort is pretty close to merge sort.

Timsort added the innovation of making mergesort in-place, plus a little
(though already common) O(*n^2) sorting for small sublists.

I've got a comparison of sort algorithms in both Cython and Pure Python
(your choice) at:
https://stromberg.dnsalias.org/~strombrg/sort-comparison/
...including a version of timsort that is in Cython or Pure Python.

HTH.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3BF7NHDWVJMPD7NQE4H2LTSLSLHPELZX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: IRC #python-dev channel is now on Libera Chat (bye bye Freenode)

[Dan Stromberg]

On Wed, May 26, 2021 at 4:25 PM Greg Ewing 
wrote:

> > On Wed, May 26, 2021 at 8:55 AM Ammar Askar  > > wrote:
> >
> > most
> > recently if your topic mentioned libera.chat, the new freenode owners
> > will take it over, ban anyone from chatting in it and change the
> topic
>
> My goodness. Let's hope the new owners eventually learn that behaving
> like spoilt 7-year-olds is no way to run a successful company.
>

Sometimes this is a cultural issue.  In at least some parts of Asia it
appears to be accepted.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/TEQJFNDNFS54LD2XZON46AL7U7ZI2TIC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Alternative syntax for Python's lambda

[Dan Stromberg]

Please see https://lwn.net/Articles/847960/

:)

On Thu, Mar 25, 2021 at 2:34 PM Ethan Furman  wrote:

> On 3/25/21 1:06 PM, Dan Stromberg wrote:
> >
> > I posted this to LWN, and thought I'd share it here too:
>
> This post is nearly completely devoid of context -- could you post a link,
> or what you are responding to, or something?
>
> --
> ~Ethan~
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/4BVRW67UU6KQCDER4FMRTZ4WUMBDTNGJ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3PBF272BZAWWF7XWP3O2PQ25VT4Y5HOO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Alternative syntax for Python's lambda

[Dan Stromberg]

I posted this to LWN, and thought I'd share it here too:

I'm opposed to terse-ifying lambda in Python.

Lambda is rarely useful in Python - you're almost always better off using a
generator expression, a list comprehension, or something from the operator
module.

And lambdas tend to give rise to the software development equivalent of a
runon sentence.

Naming a function in those rare cases that you genuinely need something
custom really isn't the end of the world, and is more readable anyway.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/KZ66M7T4E6BO3ZO4FNC4RWC3LSE6CQG5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: pth file encoding

[Dan Stromberg]

On Wed, Mar 17, 2021 at 1:11 AM Michał Górny  wrote:

> On Wed, 2021-03-17 at 13:55 +0900, Inada Naoki wrote:
> > OK. setuptools doesn't specify encoding at all. So locale-specific
> > encoding is used.
> > We can not fix it in short term.
>
> How about writing paths as bytestrings in the long term?  I think this
> should eliminate the necessity of knowing the correct encoding for
> the filesystem.
>
On Linux and many Unixes, there is no "correct" filesystem encoding.  ASCII
and UTF-8 are probably the most common encodings for individual files,
maybe even large collections of files, but nevertheless, paths are
bytestrings.  Treating paths as UTF-8 works fine for most files, but once
in a while there'll be a filename that fails to convert, and that's not the
fault of the filename.

For example, what happens if you need a file to be named touch "Ma$(echo |
tr '\012' '\361')ana" ?

For a presentation application (for EG), assuming UTF-8 is probably fine,
maybe even a good thing.  But for a filesystem backup tool, it's important
to not assume an encoding so you can back up and restore all filenames
irrespective of what the files' creators intended encodingwise.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/HLTFATPMRA57UU3KQOXHIMELZZGXUUJJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Move support of legacy platforms/architectures outside Python

[Dan Stromberg]

On Sun, Feb 21, 2021 at 4:16 AM Victor Stinner  wrote:

>
> There is also a 4th category: platforms/archs which are really not
> supported, like they legacy ones for which we removed the code :-)
> Examples: BeOS, MacOS 9, platforms with no thread support, etc.
>

FWIW, BeOS may be resurfacing somewhat, with
https://en.wikipedia.org/wiki/Haiku_(operating_system) - it's on a second
beta now.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/FQY7MYCHGWBFNYQRW5LH5YMY3IJWOFWU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Move support of legacy platforms/architectures outside Python

[Dan Stromberg]

On Sun, Feb 21, 2021 at 1:07 PM Gregory P. Smith  wrote:

>
> > I'm +1 in general for your proposal. I also like the idea to adopt
>> > Rust's platform support definition.
>>
> +1, but see below.


>
> The main thing from a project maintenance perspective is for platforms to
> not become a burden to other code maintainers.  PRs need to be reviewed.
> Every #if/#endif in code is a cognitive burden.  So being a minor platform
> can come with unexpected breakages that need fixing due to other changes
> made in the codebase that did not pay attention to the platform.  As we
> cannot expect everyone working on code to care about anything beyond the
> tier-1 fully supported platforms, buildbot or not.
>
I think #ifdef's are a big part of the problem, actually.

IIRC, the Linux kernel has been reducing/eliminating #ifdef's and instead
using different .c's for each platform's platform-specific code.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/HRXPWBJNBCRE5RMA2KFMKWB3VA6MJZG3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecate support for mingw - add to PEP 11

[Dan Stromberg]

It looks like CPython remains 100% C, so clang becomes more attractive:
https://stackoverflow.com/questions/6329688/llvm-and-visual-studio-obj-binary-incompatibility

Then again, do we allow C++ extension modules?  That might make C++ more
relevant, even if CPython itself is purely C.


On Sat, Feb 20, 2021 at 9:08 PM Dan Stromberg  wrote:

> mingw-w64 might be a small change.
>
> But while one is it at, it might make sense to evaluate:
> https://clang.llvm.org/docs/MSVCCompatibility.html
> Apparently clang on Windows is working on calling convention compatibility
> with Visual Studio.
>
>
> On Sat, Feb 20, 2021 at 8:37 PM  wrote:
>
>> I think perhaps we should admit that this build system is no longer
>> supported. From everything I can tell, the mingw project is no longer
>> maintained. The project's site, mingw.org, is no longer live; the
>> project on sourceforge, although still downloaded daily, had its last
>> commit almost 3 years ago - a commit which changed the official project URI
>> to a new link that now is also dead.
>> Looking over BPO there are a little over 50 bugs open against mingw, but
>> only 7 that have any meaningful activity within the last three years. Three
>> of those issues explicitly mention mingw-w64 which is an active fork of the
>> original mingw project (active homepage, commits almost daily, new release
>> within the last 6 months) and I wonder if this is the project the other 4
>> projects meant by "mingw"?
>> Ideally any features and flags in the code base for mingw would be
>> checked to already be working with mingw-w64 or else modified to work, but
>> this would require a sponsor for this platform, which appears to be
>> missing. Further, there is no buildbot for mingw, which should be a
>> requirement to be a fully supported platform, as per this PEP. This
>> potential work appears non-trivial with a cursory look at the
>> mingw-w64-python pacman project, which contains close to 100 patch files. I
>> am purposing instead that mingw be deprecated and, if a sponsor comes
>> along, mingw-w64 can become re-supported, or newly supported depending on
>> you point of view, as allowed by the PEP.
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/XIWF3OYL7OQRBVRBBQCBKPPJH5OKVVRC/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/HEK67QOUQ4RD42HLBDTR3CJJNEMB3HJF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecate support for mingw - add to PEP 11

[Dan Stromberg]

mingw-w64 might be a small change.

But while one is it at, it might make sense to evaluate:
https://clang.llvm.org/docs/MSVCCompatibility.html
Apparently clang on Windows is working on calling convention compatibility
with Visual Studio.


On Sat, Feb 20, 2021 at 8:37 PM  wrote:

> I think perhaps we should admit that this build system is no longer
> supported. From everything I can tell, the mingw project is no longer
> maintained. The project's site, mingw.org, is no longer live; the project
> on sourceforge, although still downloaded daily, had its last commit almost
> 3 years ago - a commit which changed the official project URI to a new link
> that now is also dead.
> Looking over BPO there are a little over 50 bugs open against mingw, but
> only 7 that have any meaningful activity within the last three years. Three
> of those issues explicitly mention mingw-w64 which is an active fork of the
> original mingw project (active homepage, commits almost daily, new release
> within the last 6 months) and I wonder if this is the project the other 4
> projects meant by "mingw"?
> Ideally any features and flags in the code base for mingw would be checked
> to already be working with mingw-w64 or else modified to work, but this
> would require a sponsor for this platform, which appears to be missing.
> Further, there is no buildbot for mingw, which should be a requirement to
> be a fully supported platform, as per this PEP. This potential work appears
> non-trivial with a cursory look at the mingw-w64-python pacman project,
> which contains close to 100 patch files. I am purposing instead that mingw
> be deprecated and, if a sponsor comes along, mingw-w64 can become
> re-supported, or newly supported depending on you point of view, as allowed
> by the PEP.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/XIWF3OYL7OQRBVRBBQCBKPPJH5OKVVRC/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7K6YOTYPFPB6IJUVCJ5WH2DA65DDGH6T/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python 0.9.1

[Dan Stromberg]

On Thu, Feb 18, 2021 at 9:39 PM David Mertz  wrote:

> As Skip pointed out to me privately, there are some minor limitations with
> this version.  E.g.:
>
> % python
> >>> import glob
> >>> import sys
> >>> print 'hello'
> hello
> >>> print 2+2
> 4
> >>> print 2*2
> Unhandled exception: run-time error: integer overflow
> Stack backtrace (innermost last):
>   File "", line 1
>

Huh.  I wonder what's different about my build:
$ /usr/local/cpython-0.9/bin/python
below cmd output started 2021 Thu Feb 18 10:24:00 PM PST
>>> 2*2
4
>>> print 2*2
4
>>>

You can download a script to build it and a bunch of other python versions
at https://stromberg.dnsalias.org/~strombrg/cpythons/
It includes all the tarballs you should need, at least for Debian. I
believe I used it on CentOS recently as well.  I haven't tried it on Ubuntu
in a while.
It depends on https://stromberg.dnsalias.org/~strombrg/cobble.html - and
I'd like to think that's its only external dependency.

HTH
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ZWLEAB5235FGFEPSEUX72CI2U57OXCU2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python 0.9.1

[Dan Stromberg]

On Thu, Feb 18, 2021 at 12:02 AM Paul Sokolovsky  wrote:

> I think to resolve this issue to the completion, and avoid possibility
> of an intermediary to add any unexpected changes/mistakes to the
> original sources, instead of "someone making a tarball", someone should
> make a script, which reproduces making a tarball. Then such a script
> can be reviewed and tarball reproduced independently (e.g., by the
> admins of python.org).
>
> That's exactly what I did, and attached it to the ticket above:
> https://github.com/python/pythondotorg/issues/1734#issuecomment-781129337
>
> For extra details, copying my comment there:
>
> ---
> I attach my version of such a script (and also paste it below for
> reference, but if you use it, please use the attached version to avoid
> any discrepancies due to copy-paste).
>

I got a version to build, but what's supposed to be in patchlevel.h?  It
was just an int, but that was confusing gcc.  I commented out its #include,
and things seemed to work without it.  The patches I used are at
https://stromberg.dnsalias.org/svn/cpythons/trunk/python0.9/exportable-patches

Sadly, it doesn't work that well with my "pythons" script (
https://stromberg.dnsalias.org/~strombrg/pythons/), because 0.9.1's
interpreter doesn't have a -c option.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/XAKEELGLCWOVW77F4PV2S6MYSC7YFXZR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

[Dan Stromberg]

But this message seems to say "Argue with me!"
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/SST7KKKTJAEHU73TMWS7GIIR3GNELZA6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

[Dan Stromberg]

On Fri, Feb 12, 2021 at 2:26 PM Chris Angelico  wrote:

> On Sat, Feb 13, 2021 at 6:58 AM Dan Stromberg  wrote:
> > I believe Python needs to become more independent of CPython, for
> Python's long term health.
> >
>
> Since 1997, Python has been defined independently of CPython.

Really?  It sounds like I missed something important then.  More
specifically, what changed in 1997?

There
> are numerous documents that define the language semantics for the
> benefit of other implementations.

References please?  I'd love to find out this has already been done.

Multiple implementations have
> somehow managed to exist without any sort of ISO standard.
>
Yes, the existence of a small number of other implementations (modulo web
implementations) is why I say Python has done pretty well despite the
existence of a reference implementation,

Can you explain what would be improved by having a formalized
> standard?

It's mostly about avoiding creeping featurism and painting other
implementations into corners.  Or - and this is equally important - leaving
other implementations in the dust.

Consider how far back Jython and IronPython are.  If the "bureaucracy" (I
see it as measured progress) of a standard would allow them to catch up,
without having to study the CPython source code, the standard will have
done its job.

In all candor, I do not think that frequent releases with significant new
features in each are good for a language. I'll remind you that the
complexity of a language varies with the square of its feature count.

There's probably been a rush to add features in the wake of the 2.x-to-3.x
transition, but hopefully we won't be continuing at that pace.

And again: a good language has a small core but is extensible, enabling
extensive /libraries/.  Python is indeed nicely extensible.

So far this thread has just been vague ideas that a
> bureaucratic procedure will somehow help things, without showing a
> problem.
>
I've outlined some, but you seem more than ready to dismiss them.

The things that got me thinking about this were:
1) The caution my comparative languages professor in school delivered about
reference implementations and how bad they can be for a language's
maturation.
2) A comment on python-list about languages without standards not being
grown up, that I really couldn't disagree with.
3) The common confusion between "Python" and "CPython".  Many people still
think they're the same thing.

Of course, Java is grown up and it has no formal standard.  But there's
always Perl's scary example lurking in the background.  And even Java
really doesn't appear to have that many competing implementations.  I'm
aware of the IBM JDK, OpenJDK, and gcj.  But for all Java's success, there
probably should be (have been) more.

And having a comprehensive test suite can help a lot too - it sounds like
we're pretty close there?  ISTR hearing that Pypy was able to reuse much of
CPython's test suite.  Having a generic test suite that isn't tied to a
specific implementation would be fantastic.  One could argue this is what
has given rise to the alternative implementations of Python we have.
Unless you count the ones that run in a web browser - there were at least
32 at my last count, with frequently-superficial compatibility.

But we really should encourage more compatible implementations.  That's
what I'm trying to get at.  That's probably the main "problem" you seem to
want me to highlight, even though I'd rather not be very critical.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/COZK5QPWEAAVOAAILD7GKIYMJMORX6NG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

[Dan Stromberg]

On Fri, Feb 12, 2021 at 2:01 PM Greg Ewing 
wrote:

> On 13/02/21 9:03 am, Paul Bryan wrote:
> > What if PSF were to undertake codifying a language specification?
>
> We have the Language Reference and Library Reference. Do they
> not count as specifications?
>
It's been a long time since I looked at these, but aren't they more
targeted at people developing in Python than people developing a Python
implementation?  The two have some overlap of course, but they aren't
really the same thing.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/QXIAEFI2T7H32QIY6QNCZZVFULMSX7GL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

[Dan Stromberg]

That could be good.  :)  And sometimes standards are rubber stamped by
other bodies.

On Fri, Feb 12, 2021 at 12:03 PM Paul Bryan  wrote:

> What if PSF were to undertake codifying a language specification?
>
> On Fri, 2021-02-12 at 11:57 -0800, Dan Stromberg wrote:
>
>
> On Fri, Feb 12, 2021 at 11:02 AM Ivan Pozdeev via Python-Dev <
> python-dev@python.org> wrote:
>
> How a standard by ANSI, ECMA and/or ISO is any better than a standard by
> the PSF?
>
> I don't think what the PSF is producing is truly a standard.
>
> Is PSF bad at "controlling its growth and avoiding featuritis" in your
> opinion or smth?
>
> It's not the PSF I have an issue with. It's having a reference
> implementation.
>
> I think the PSF has done a pretty good job of keeping in mind what other
> Python implementations can realistically do also - but doing so is an
> uphill battle.
>
> I believe Python needs to become more independent of CPython, for Python's
> long term health.
>
> Think of C.  Where would it be if it had K C as a reference
> implementation, long term?  There are dozens, maybe hundreds of
> mostly-compatible implementations of C.  I think this should be Python's
> goal.
>
> Look where not having a standard got Perl.  It is so defined by a single
> implementation that the language is collapsing under its own weight.  Perl
> 6 is so not-perl that it was renamed.  Python is much less guilty of
> exuberant design, that's part of what I like about Python, but like I said,
> having a reference implementation instead of a standard makes that more
> difficult.
>
> On 12.02.2021 21:33, Dan Stromberg wrote:
>
>
> What would it take to create an ANSI, ECMA and/or ISO standard for Python?
>
> It seems to have really helped C.
>
> It looks like Java isn't standardized, and it's done OK, though perhaps it
> was healthier in the past - before Oracle decided API's were ownable.
>
> I think standardizing Python might be really good for controlling its
> growth and avoiding featuritis.
>
>
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to 
> python-dev-leave@python.orghttps://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/JZYW4JOTANYIOLYDQ6YHRUP2TWO52OAE/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/7WXKZFTLABA7L63LRWVVCLCEHZ5NDGRO/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/36ZVB2LUBRZOLXT4EJ2YCVUYSJ6L4HPB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

[Dan Stromberg]

On Fri, Feb 12, 2021 at 11:02 AM Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:

> How a standard by ANSI, ECMA and/or ISO is any better than a standard by
> the PSF?
>
I don't think what the PSF is producing is truly a standard.

> Is PSF bad at "controlling its growth and avoiding featuritis" in your
> opinion or smth?
>
It's not the PSF I have an issue with. It's having a reference
implementation.

I think the PSF has done a pretty good job of keeping in mind what other
Python implementations can realistically do also - but doing so is an
uphill battle.

I believe Python needs to become more independent of CPython, for Python's
long term health.

Think of C.  Where would it be if it had K C as a reference
implementation, long term?  There are dozens, maybe hundreds of
mostly-compatible implementations of C.  I think this should be Python's
goal.

Look where not having a standard got Perl.  It is so defined by a single
implementation that the language is collapsing under its own weight.  Perl
6 is so not-perl that it was renamed.  Python is much less guilty of
exuberant design, that's part of what I like about Python, but like I said,
having a reference implementation instead of a standard makes that more
difficult.

> On 12.02.2021 21:33, Dan Stromberg wrote:
>
>
> What would it take to create an ANSI, ECMA and/or ISO standard for Python?
>
> It seems to have really helped C.
>
> It looks like Java isn't standardized, and it's done OK, though perhaps it
> was healthier in the past - before Oracle decided API's were ownable.
>
> I think standardizing Python might be really good for controlling its
> growth and avoiding featuritis.
>
>
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to 
> python-dev-leave@python.orghttps://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/JZYW4JOTANYIOLYDQ6YHRUP2TWO52OAE/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> --
> Regards,
> Ivan
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/ZBKXMHWFEIWGP7FZJDZPNPV7TEXANMIV/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7WXKZFTLABA7L63LRWVVCLCEHZ5NDGRO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

[Dan Stromberg]

On Fri, Feb 12, 2021 at 10:51 AM Paul Bryan  wrote:

> From my point of view, the process of standardizing through a formal
> standards body is a tedious, verbose, laborious, bureaucratic and
> often contentious process.
>
I've never participated in such a standardization, but I'm sure it's hard
work.

I'd really like to know quantitatively what the benefits would be of
> running that gauntlet, as I'm not sure they would outweigh the costs.
>
I think it'd be easier to quantify love.

On Fri, 2021-02-12 at 10:33 -0800, Dan Stromberg wrote:
>
>
> What would it take to create an ANSI, ECMA and/or ISO standard for Python?
>
> It seems to have really helped C.
>
> It looks like Java isn't standardized, and it's done OK, though perhaps it
> was healthier in the past - before Oracle decided API's were ownable.
>
> I think standardizing Python might be really good for controlling its
> growth and avoiding featuritis.
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/JZYW4JOTANYIOLYDQ6YHRUP2TWO52OAE/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NC5RVQ55OENLR3AFB6SDXL5AMHHHA2MD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Python standardization

[Dan Stromberg]

What would it take to create an ANSI, ECMA and/or ISO standard for Python?

It seems to have really helped C.

It looks like Java isn't standardized, and it's done OK, though perhaps it
was healthier in the past - before Oracle decided API's were ownable.

I think standardizing Python might be really good for controlling its
growth and avoiding featuritis.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JZYW4JOTANYIOLYDQ6YHRUP2TWO52OAE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: nanosecond stat fields, but not os.path methods ?

[Dan Stromberg]

On Mon, Dec 7, 2020 at 10:52 AM Antoine Pitrou  wrote:

> On Mon, 7 Dec 2020 16:19:02 +
> David Mertz  wrote:
> > Are there any filesystems that can actually record a meaningful ns
> > modification time?  I find discussions claiming this:
> >
> > - XFS and EXT3: second precision
> > - EXT4: millisecond precision
> > - NTFS: 100ns precision
> > - APFS: 1 ns precision
> >
> > But also notes that the precision is likely to exceed the accuracy by
> many
> > times on real systems.
>
> Even if the accuracy is much lower than that, it can be important to
> reproduce exact timestamps.
>

EG GNU tar --diff
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/E4IWRUBU4SUXP4VAEOB3UQTVZUBW2BLO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

[Dan Stromberg]

On Sat, Oct 31, 2020 at 9:37 PM Guido van Rossum  wrote:

>
> I think this over-stresses the notion that users might want to override
> the comparison operator to be used. We only have two operators that make
> sense in this context, 'is' and '==', and really, for almost everything you
> want to do, '==' is the appropriate operator. (There is a small trickle of
> bugs caused by people inappropriately using e.g. `if x is 1` instead of `if
> x == 1`, suggesting that if anything, there is too much freedom here.) The
> big exception is `None`, where you basically always want to use `is`, which
> is what PEP 634 does.
>
FWIW, there's an additional exception:
sentinel = object()

if var is sentinel:

I use this idiom from time to time - instead of None.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VVOITSG54OTVBDTZGGRW7NTTAAG4EIQU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

[Dan Stromberg]

On Tue, Oct 20, 2020 at 9:33 AM Steven D'Aprano  wrote:

> > What would happen if $2M were spent on improving PyPy3 instead?
>
> Then both of the PyPy3 users will be very happy *wink*
>

Wow, I didn't know I was 50% of Pypy3 users :)

Anyway, Pypy3 is already pretty great.  I'm sure it can be improved, but I
suspect what it needs most is HPY work, which could benefit a lot of Python
language implementations in the long term:
https://github.com/hpyproject/hpy

$2e6 spent on HPY could be pretty amazing.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/OJCDOMSSK2DICZARJZMZ2SOQAKIDPZ4Q/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 638: Syntactic macros

[Dan Stromberg]

On Sat, Sep 26, 2020 at 5:11 AM Mark Shannon  wrote:

> Hi everyone,
>
> I've submitted my PEP on syntactic macros as PEP 638.
> https://www.python.org/dev/peps/pep-0638/
>

Speaking as a former C developer, why do "We need to let the community
develop their own extensions"?  What's insufficient about Python's current
extensibility?

The complexity of a language varies with the square of its feature count,
and adding macros intended for creation of domain-specific language
features  balloons the feature count. Granted, they don't much increase the
complexity of CPython, the language implementation, but the de facto
language then becomes more than CPython - potentially a lot more.

That is, making it easier to extend python means a proliferation of
extensions with little thought given to their long term viability or
cross-domain compatibility.

It's kind of like zsh vs. bash.  zsh has a smaller implementation, but a
larger _language_.  For this reason, I'm not terribly interested in zsh,
but I like bash.  On the other hand, bash has seen a proliferation of
unnecessary extensions in recent years, so I may jump ship to something
else someday - something with a smaller language, that isn't afraid of
fork+exec.

I've used m4 before as a macro system for Python+Cython, but I would never
consider suggesting that m4 should become part of Python itself.

IMO Perl is dying because of its exuberant design.  One of the most
important things a language designer has to do is say "no" sometimes.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/AKKHSCE6IS3IW7MBJ3TP5253EXG5NWZO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Dan Stromberg]

On Fri, Mar 20, 2020 at 3:28 PM Victor Stinner  wrote:

> > The builtin ``str`` class will gain two new methods with roughly the
> > following behavior::
> >
> > def cutprefix(self: str, pre: str, /) -> str:
> > if self.startswith(pre):
> > return self[len(pre):]
> > return self[:]
>

I tend to be mistrustful of code that tries to guess the best thing to do,
when something expected isn't found.

How about:

def cutprefix(self: str, pre: str, raise_on_no_match: bool=False, /) -> str:
if self.startswith(pre):
return self[len(pre):]
if raise_on_no_match:
raise ValueError('prefix not found')
return self[:]
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NYMLVK35CVNWUL6OWZDB2CRA5W2HPMIH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Slow down...

[Dan Stromberg]

When I think of why Python is so far ahead of Perl in language design,
I think it's simply that Python is the result of cautious design, and
Perl is the result of exuberant design.

I think Python is in danger of becoming a large language - which isn't
a good thing.

A great language, like Scheme or Python or even C, is a language that
has a small, very useful core, and large _libraries_.

I'd very much like a live in a world where Jython and IronPython and
MicroPython and Cython and Pyjamas can all catch up and implement
Python 3.7, 3.8, and so forth.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

[Dan Stromberg]

On Tue, Apr 24, 2018 at 2:21 AM, Victor Stinner  wrote:
> == Write code for babies! ==
>
> Please don't write code for yourself, but write code for babies! :-)
> These babies are going to maintain your code for the next 5 years,
> while you moved to a different team or project in the meanwhile. Be
> kind with your coworkers and juniors!

I don't like the idea of assignment expressions in Python.

“Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.”

- Brian Kernighan

Of the proposed syntaxes, I dislike identifer := expression less, but
I'd still rather not see it added.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Replacing self.__dict__ in __init__

[Dan Stromberg]

On Sun, Mar 25, 2018 at 9:51 AM, Serhiy Storchaka  wrote:
> 25.03.18 18:38, Tin Tvrtković пише:
>>
>> For example, for a simple class with 9 attributes:
> What are results for classes with 2 or 100 attributes? What are results in
> Python 3.5?
>
> I think you are playing on thin ice. Your results depend on implementation
> details of the bytecode
>
> I suggest you to not worry and just wait for more general optimizations in
> CPython interpreter.

Indeed, sometimes strange code that was once faster, is made slower
than the favored way by a future version of your favorite python
interpreter.

I hope there are more important things to worry about?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Any way to only receive emails for threads that I am participating in?

[Dan Stromberg]

On Fri, Mar 2, 2018 at 6:15 PM, Elias Zamaria  wrote:
> It seems like I can either subscribe and get emails for all of the threads,
> or unsubscribe and not get any emails, making me unable to reply to the
> threads I want to reply to. The batched daily digest feature makes the
> emails more tolerable, but ideally, I would like to only get emails for a
> few specific subjects I care a lot about.

Maybe gmane combined with a threaded newsreader (NNTP client) would be
close enough?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Dan Stromberg]

On Wed, Feb 21, 2018 at 2:19 PM, Barry Warsaw  wrote:
> On Feb 21, 2018, at 13:22, Guido van Rossum  wrote:
>>
>> I'm willing to reconsider if there's a good enough tool. Ditto for C code 
>> (or do we already do it for C?).
>
> For Python code, flake8 --possibly with our own custom plugins— is the way to 
> go.

Is flake8 that much better than pylint, that pylint wouldn't even be discussed?

pylint does warn about some relatively unimportant things out of the
box, but it can be configured to ignore (almost?) everything it
checks.

I've been editing Python code in vim with syntastic.  I have syntastic
set up to run pyflakes, pycodestyle and pydocstyle.  And I have a
macro that saves the buffer, shells out and runs "make" with the
default rule - and that default rule almost always does a
whole-program pylint.

It's possible to make pylint check just one file from syntastic, but I
don't do that because it's too slow on large files.

I've gotten the impression that pylint can detect some errors that
pyflakes misses.  Not sure about flake8.

I do like it that flake8 has a mccabe check.  pylint doesn't appear to
have that, and instead relies on things like "too many statements",
"too many branches" and "too many variables".
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How to set/update value in a xml file using requests in python

[Dan Stromberg]

This is more relevant to python-list than python-dev. I've added
python-list to the To header.

Gmail doesn't appear to allow setting a reply-to for a single message,
so I've not set that; please, when replying, drop python-dev from the
to: header.

You'll likely want to set up some kind of REST endpoint to allow
updating your xml file.  Imagine if anyone could change anyone else's
xml files - it'd be pretty chaotic.

Perhaps flask would be appropriate?
http://flask.pocoo.org/docs/0.12/quickstart/

You likely will want a PUT or a POST HTTP verb:
https://stackoverflow.com/questions/107390/whats-the-difference-between-a-post-and-a-put-http-request

HTH.

On Thu, Feb 8, 2018 at 12:38 AM, Sum J  wrote:
> My xml file is located in local network:
>
> http://192.168.43.109/DevMgmt/NetAppsDyn.xml
>
> Below is a part content of above xml I want to update :
>
> 
>
> 
> 
> 
> off
> 
>
> 
>
> I want to set the value for 'ResourceUI' and 'Port' field in above xml.
>
> I have used below code :
>
>  import requests
>  data = {
>   'ResourceURI':'web-proxy.xxx.yy.com',
>   'Port':8080
> }
>
> URL = 'http://192.168.75.165/DevMgmt/NetAppsDyn.xml'
>
> # content type
> head = {'Content-type': 'text/xml'}
> # sending get request
> gr= requests.get(url=URL)
> print gr
>
> # sending put request
> r = requests.put(url=URL, data=data,headers=head)
> print r.status_code
> # extracting response text
> output_xml = r.text
> print("The op xml is:%s" % output_xml)
>
> Issue : The fields are not getting updated in xml using put request. I am
> able to see the response for get (request) , but for put request it is
> throwing errror code : 301 , resource has been moved permanently.
>
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/drsalists%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Is 4.0 a major breaking changes release?

[Dan Stromberg]

On Sat, Feb 3, 2018 at 2:40 PM, Alex Walters  wrote:
> I am still working on porting code from 2.x to 3.x.  As of late on the lists
> I've seen comments about making somewhat major changes in 4.0 - now I'm
> concerned that I should pause my porting effort until that is released.  Is
> python 4 going to be another python 3?

https://www.curiousefficiency.org/posts/2014/08/python-4000.html

Python 0.x to 1.x was a small change.
Python 1.x to 2.x was a small change.

I doubt there'll be anything as important as str -> (bytes, unicode)
to merit a breaking change.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecate crypt module and revert PR 3854

[Dan Stromberg]

On Fri, Feb 2, 2018 at 12:31 PM, Antoine Pitrou  wrote:
> On Fri, 2 Feb 2018 16:23:20 +0100
> Christian Heimes  wrote:
>> Hi,
>>
>> in PR 3854 [1] Serhiy added blowfish, extended DES and NT-Hash to
>> Python's crypt mdodule. I vetoed against addition of the APIs because
>> all these hashing algorithms are not state of the art. Their quality
>> ranges from old to horribly, horriblye broken beyond any repair.
>>
>> Shortly after the PR has landed, I was made aware that glibc has
>> deprecated crypt(3) API [2] and favor of an external library called
>> libxcrypt [3] from OpenWall Linux. I have patched Python 3.7 [4] to
>> support libxcrypt.
>>
>> In light of deprecation of crypt(3) glibc function and bad quality of
>> hashing algorithms, I'd like to raise the motion to revert 3854 and
>> deprecate the crypt module.
>
> Those are two separate proposals.
>
> On the topic of reverting PR #3854, I don't see the point.  Is Blowfish
> more fragile than the other algorithms?  If not, it sounds ok to add it.

I'm no cryptographer, but I believe Blowfish's author recommends using
Twofish instead now.

> On the topic of deprecating the crypt module, that doesn't sound like a
> good idea right now.  People may need to generate crypt()-compatible
> output for various reasons, such as being able to automate system
> administration tasks.

Encryption algorithms continue to be needed even after the time at
which they should no longer be used in new code.  But they probably
should be documented as deprecated and warned about at runtime - after
there are suitable alternatives.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Guido's Python 1.0.0 Announcement from 27 Jan 1994

[Dan Stromberg]

We probably should (if possible) create an archive (with dates) of
very old (or all, actually) versions of CPython, analogous to what The
Unix Heritage Society does for V5, V7, etc., but for CPython...

Or is there one already?  I found a bunch of 1.x's, but no 0.x's.
What I found was at http://legacy.python.org/download/releases/src/

I realize modern OS's and C compilers won't cope with them anymore,
and there'll be some security holes so you wouldn't use them in
production, but it'd be an interesting history lesson to set up a
matching set for the various releases using virtualboxes or something.

I've been getting some mileage, actually, out of:
http://stromberg.dnsalias.org/svn/cpythons/trunk/  (build cpythons 2.4
and up, and stash them each in /usr/local/cpython-*)
...and:
http://stromberg.dnsalias.org/svn/pythons/trunk/  (run python code on
a variety of interpreters to test for compatibility, including a bunch
of CPythons, some pypys, jython, micropython, hopefully more someday,
like maybe nuitka)

It'd be kind of cool to add an authenticated way of running python
commands on a remote host to check even older versions.

I tried to get "cpythons" to build cpython 2.3 on a modern Linux, but
it didn't appear practical.  But 2.4 and up have been working well.

On Sat, Jan 27, 2018 at 1:57 PM, Guido van Rossum  wrote:
> Actually Python was born in December 1989 and first released open source in
> February 1991. I don't recall what version number that was, perhaps 0.1.0.
> The 1994 date was just the release of 1.0!
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python should be easily compilable on Windows with MinGW

[Dan Stromberg]

But what do you really think?

IMO, windows builds probably should do both visual studio and mingw.
That is, there probably should be two builds on windows, since there's
no clear consensus about which to use.

I certainly prefer mingw over visual studio - and I have adequate
bandwidth for either.


On Fri, Feb 26, 2016 at 9:55 AM, Alexander Walters
 wrote:
> No.
>
> Visual Studio is a solid compiler suit, mingw is a jenky mess, especially
> when you try and move to 64bit (where I don't think there is one true
> version of mingw).  I'm sorry that Visual Studio makes it very hard for you
> to contribute, but changing THE compiler of the distribution from the
> platform compiler, especially when we FINALLY got a stable abi with it, is
> going to be a non starter.
>
> Compiling on MinGW for your own edification is fine, but that's not the
> build platform for windows python, nor should it be. Contributions are, and
> should continue to be, tested against Visual Studio.
>
>
> On 2/26/2016 05:12, Mathieu Dupuy wrote:
>>
>> Hi.
>> I am currently working on adding some functionality on a standard
>> library module (http://bugs.python.org/issue15873). The Python part
>> went fine, but now I have to do the C counterpart, and I have ran into
>> in several problems, which, stacked up, are a huge obstacle to easily
>> contribute further. Currently, despite I could work, I can't go
>> further
>> on my patch.
>>
>> I am currently working in very limited network, CPU and time
>> ressources* which are quite uncommon in the western world, but are
>> much less in the rest of the world. I have a 2GB/month mobile data
>> plan and a 100KB/s speed. For the C part of my patch, I should
>> download Visual Studio. The Express Edition 2015 is roughly 9GB. I
>> can't afford that.
>>
>> I downloaded Virtualbox and two Linux netinstall (Ubuntu 15.10 and
>> Fedora 23). Shortly, I couldn't get something working quickly and
>> simply (quickly = less than 2 hours, downloading time NOT included,
>> which is anyway way too already much). What went wrong and why it went
>> wrong could be a whole new thread and is outside of the scope of this
>> message.
>> Let me precise this : at my work I use many virtualbox instances
>> automatically fired and run in parallel to test new deployments and
>> run unittests. I like this tool,
>> but despite its simple look, it (most of the time) can not be used
>> simply by a profane. The concepts it requires you to understand are
>> not intuitive at first sight and there is *always* a thing that go
>> wrong (guest additions, mostly).(for example : Ubuntu and Virtualbox
>> shipped for a moment a broken version of mount.vboxsf, preventing
>> sharing folder to mount. Despite it's fixed, the broken releases
>> spread everywhere and you may encounter them a lot in various Ubuntu
>> and Virtualbox version. I downloaded the last versions of both and I
>> am yet infected. https://www.virtualbox.org/ticket/12879). I could do
>> whole new thread on why you can't ask newcomers to use Virtualbox
>> (currently, at least).
>>
>> I ran into is a whole patch set to make CPython compile on MinGW
>> (https://bugs.python.org/issue3871#msg199695). But it is not denying
>> it's very experimental, and I know I would again spent useless hours
>> trying to get it work rather than joyfully improving Python, and
>> that's exactly what I do not want to happen.
>>
>> Getting ready to contribute to CPython pure python modules from an
>> standard, average mr-everyone Windows PC for a beginner-to-medium
>> contributor only require few megabytes of internet and few minutes of his
>> time: getting a tarball of CPython sources (or cloning the github CPython
>> mirror)**, a basic text editor and msys-git. The step further, if doing
>> some -even basic- C code is required, implies downloading 9GB of Visual
>> Studio and countless hours for it to be ready to use.
>> I think downloading the whole Visual Studio suite is a huge stopper to
>> contribute further for an average medium-or-below-contributor.
>>
>> I think (and I must not be the only one since CPython is to be moved
>> to github), that barriers to contribute to CPython should be set to
>> the lowest.
>> Of course my situation is a bit special but I think it represents
>> daily struggle of a *lot* of non-western programmer (at least for
>> limited internet)(even here in Australia, landline limited internet
>> connections are very common).
>> It's not a big deal if the MinGW result build is twenty time slower or
>> if some of the most advanced modules can't be build. But everyone
>> programmer should be able to easily make some C hacks and get them to
>> work.
>>
>> Hoping you'll be receptive to my pleas,
>> Cheers
>>
>>
>> * I am currently picking fruits in the regional Australia. I live in a van
>> and have internet through with smartphone through an EDGE connection. I
>> can
>> plug the laptop in the farm but not in the van.
>> ** No fresh programmer use 

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

[Dan Stromberg]

On Thu, Dec 11, 2014 at 11:35 AM, Mark Roberts wiz...@gmail.com wrote:
 I disagree. I know there's a huge focus on The Big Libraries (and wholesale
 migration is all but impossible without them), but the long tail of
 libraries is still incredibly important. It's like saying that migrating the
 top 10 Perl libraries to Perl 6 would allow people to completely ignore all
 of CPAN. It just doesn't make sense.

Things in the Python 2.x vs 3.x world aren't that bad.

See:
https://python3wos.appspot.com/ and
https://wiki.python.org/moin/PortingPythonToPy3k
http://stromberg.dnsalias.org/~strombrg/Intro-to-Python/ (writing code
to run on 2.x and 3.x)

I believe just about everything I've written over the last few years
either ran on 2.x and 3.x unmodified, or ran on 3.x alone.  If you go
the former route, you don't need to wait for your libraries to be
updated.

I usually run pylint twice for my projects (after each change, prior
to checkin), once with a 2.x interpreter, and once with a 3.x
interpreter (using
http://stromberg.dnsalias.org/svn/this-pylint/trunk/this-pylint) , but
I gather pylint has the option of running on a 2.x interpreter and
warning about anything that wouldn't work on 3.x.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Python 2.x vs 3.x survey - new owner?

[Dan Stromberg]

Last year in late December, I did a brief, 9 question survey of 2.x vs
3.x usage.

I like the think the results were interesting, but I don't have the
spare cash to do it again this year.  I probably shouldn't have done
it last year.  ^_^

Is anyone interested in taking over the survey?  It's on SurveyMonkey.

It was mentioned last year, that it might be interesting to see how
things change, year to year.  It was also reported that some people
felt that late December wasn't necessarily the best time of year to do
the survey, as a lot of people were on vacation.

The Python wiki has last year's results:
https://wiki.python.org/moin/2.x-vs-3.x-survey
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mUTF-7 support?

[Dan Stromberg]

On Thu, Oct 9, 2014 at 3:47 PM, Jesus Cea j...@jcea.es wrote:
 I miss mUTF-7 support (as used to encode IMAP4 mailbox names) in Python,
 in the codecs module. As an european with a language with 27 different
 letters (instead of english 26), tildes, opening question marks, etc., I
 find it very inconvenient.

 This encoding is used basically only in IMAP4, I know. But IMAP4 is an
 important protocol and all projects related to it needs mUTF-7 support
 if they care about non-english alphabets. Everybody has already an
 implementation, waste of effort.

I've been parsing up a huge gmail account with no encoding errors,
using CPython 2.x and CPython 3.x.  I'd be surprised if there are no
foreign characters in any of the thousands of messages there - but
maybe I'm just being very lucky.  I'm not specifying a codec, and I
don't see a way of specifying one offhand.

Does email.header.decode_header help you?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

[Dan Stromberg]

On Sun, Aug 31, 2014 at 3:28 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
 Victor Stinner wrote:

 As written in the PEP, if you want to be notified of the signal, set a
 signal handler which raises an exception.

 I'm not convinced that this covers all possible use cases.
 It might be all right if you have control over the signal
 handler, but what if you don't?

 I think it's best if the functions in the os module remain
 thin wrappers that expose the OS functionality as fully and
 directly as possible. Anything else should be provided
 by higher-level facilities.

I'm inclined to agree about keeping the os module thin.  If we were to
recreate Python today, from scratch, it might make sense to hide this
by default, but now there's almost certainly code out there that
depends on the current behavior.

But I also agree that it's hard to pin down which higher level Python
library calls are going to be using system calls.  My
http://stromberg.dnsalias.org/~strombrg/pypty/ program had a problem
with window resizing for a while (SIGWINCH), and although I use it
pretty much daily now without problems, I'm still not sure I got 100%
of the possibilities covered.

Fortunately, wrapping a system call can be as simple as:

def retry_on_eintr(function, *args, **kw):
'''
Retry a system call until one of the following happens:
1) It succeeds
2) It errors with something other than EINTR
'''

while True:
try:
return function(*args, **kw)
except OSError:
nothing, extra, nothing2 = sys.exc_info()
dummy = nothing
dummy = nothing2
if extra.errno == errno.EINTR:
continue
else:
raise

Note that os.read() and os.write() need different handling.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] collections.sortedtree

[Dan Stromberg]

vne
On Mon, Mar 31, 2014 at 2:01 PM, Daniel Stutzbach stutzb...@google.com wrote:
 On Fri, Mar 28, 2014 at 6:45 PM, Dan Stromberg drsali...@gmail.com wrote:

 In my testing blist.sorteddict was dead last for random keys, and
 wasn't last but was still significantly underperforming for sequential
 keys (outperforming only binary tree and scapegoat tree, behind all
 others):


 http://stromberg.dnsalias.org/~strombrg/python-tree-and-heap-comparison/2014-03-18/


 Could you post the source code for your test tools, so that I can reproduce
 them locally and understand the results better?

 I think I'm confused about what you're trying to measure.  It looks like the
 tests perform get and set operations, neither of which required a sorted
 dict.  Wouldn't a good comparison of sorted dict types include at least one
 operation that relies on the sorted property?  Possibly I've misunderstood
 how your tests work.

The code is at 
http://stromberg.dnsalias.org/svn/python-tree-and-heap-comparison/trunk/

You're right, I'm not comparing find_min, find_max, generate_in_order
or generate_reverse_order.  The first two tend to be the same as
find_arbitrary.

I've been thinking about trying to import some C extension module
trees, and just ignoring them if they fail to import.  But I haven't.

Trunk only compares pure python implementations - even for treap,
which has a cython version.  I tossed my changes after checking blist.

Trunk does operations/second.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] collections.sortedtree

[Dan Stromberg]

On Fri, Mar 28, 2014 at 5:48 PM, Daniel Stutzbach stutzb...@google.com wrote:
 On Fri, Mar 28, 2014 at 2:54 PM, Marko Rauhamaa ma...@pacujo.net wrote:

 The blist implementation, which I have taken a quick glance at,

 buys cache locality at the price of block copying; I have no data to
 decide if the tradeoff is a good one.


 There's actually a compile-time parameter so that you can tune the tradeoff
 by adjusting how wide each of blist's nodes are. Like most tradeoffs,
 whether it's good or bad depends on what you're trying to do.  RedBlack
 trees are very similar to a B-tree with a node-width of 4:
 http://en.wikipedia.org/wiki/Red%E2%80%93black_tree#Analogy_to_B-trees_of_order_4

 blist's sorteddict is written in Python on top of the blist type (which is
 written in C).  Because of the Python layer, it's slower by a constant
 factor compared to pure-C implementations in microbenchmarks.

It grieves me a bit to say this, and blist and blist's sorteddict are
probably a good tool for an appropriate job, but blist's sorteddict
type is quite a bit slower than several pure python implementations of
dictionaries with ordered keys.

In my testing blist.sorteddict was dead last for random keys, and
wasn't last but was still significantly underperforming for sequential
keys (outperforming only binary tree and scapegoat tree, behind all
others):

http://stromberg.dnsalias.org/~strombrg/python-tree-and-heap-comparison/2014-03-18/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] collections.sortedtree

[Dan Stromberg]

On Wed, Mar 26, 2014 at 1:55 PM, Benjamin Peterson benja...@python.org wrote:
 On Wed, Mar 26, 2014, at 13:31, Marko Rauhamaa wrote:

 I have made a full implementation of a balanced tree and would like to
 know what the process is to have it considered for inclusion in Python
 3.

 It's not a bad idea. (I believe others have proposed an red-black tree.)
 Certainly, it requires a PEP and a few months of bikesheding, though.

I'd recommend a plain binary tree (for random keys), red-black tree
and treap (both for ordered or mostly-ordered keys, where red-black
tree gives low operation duration standard deviation, and treap gives
low average operation duration).

https://en.wikipedia.org/wiki/Binary_search_tree#Performance_comparisons
http://stromberg.dnsalias.org/~strombrg/python-tree-and-heap-comparison/

It'd likely make sense to have either a pure python implementation, or
pure python and C-extended, so that Pypy and Jython can share the
feature with CPython.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] collections.sortedtree

[Dan Stromberg]

On Wed, Mar 26, 2014 at 3:52 PM, Marko Rauhamaa ma...@pacujo.net wrote:
 Dan Stromberg drsali...@gmail.com:

 It'd likely make sense to have either a pure python implementation, or
 pure python and C-extended, so that Pypy and Jython can share the
 feature with CPython.

 Jython can build directly on Java's native SortedMap implementation. The
 API should not tie it to a tree. Optimizations and refactorings should
 be allowed. Only O(log N) worst-case behavior should be mandated.

Rare worst cases should be fine for a good reason - see python dict's.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Python 3 marketing document?

[Dan Stromberg]

Has anyone published a web page or wiki page about what's great about
Python 3.x?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python3 complexity (was RFC: PEP 460: Add bytes...)

[Dan Stromberg]

On Wed, Jan 8, 2014 at 2:04 PM, Kristján Valur Jónsson
krist...@ccpgames.com wrote:

 Believe it or not, sometimes you really don't care about encodings.
 Sometimes you just want to parse text files.  Python 3 forces you to think 
 about abstract concepts like encodings when all you want is to open that .txt 
 file on the drive and extract some phone numbers and merge in some email 
 addresses.  What encoding does the file have?  Do I care?  Must I care?

If computers had taken off in China before the USA, you'd probably be
wondering why some Chinese refuse to care about encodings, when the
rest of the world clearly needs them.

Yes, you really should care about encodings.  No, it's not quite as
simple as it once was for English speakers as it once was.  It was
formerly simple (for us) because we were effectively pressing everyone
else to read and write English.

If you want to keep things close to what you're used to, use latin-1
as your encoding.  It's still a choice, and not a great one for
user-facing text, but if you want to be simplistic about it, that's a
way to do it.

That said, there will be some text that isn't user-facing, EG in a
network protocol.  This is probably what all the fuss is about.  But
like I said, this can be done with latin-1.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.x vs 3.x survey results

[Dan Stromberg]

On Sat, Jan 4, 2014 at 8:20 PM, John Yeuk Hon Wong
gokoproj...@gmail.com wrote:

 I think it helps Luca and many others (including myself) if there is a
 reference of the difference between 2.7 and Python 3.3+.
 There are PEPs and books, but is there any such long list of references?

 If not, should we start investing in one? I know the basic one such as
 xrange and range, items vs iteritems, izip vs zip that sort of uniform
 syntax/library inclusion difference.

 If there is such reference available?

This isn't comprehensive, but it does cover the issues I ran into
while writing a backup program (of about 7,000 lines) that runs on 2.x
and 3.x, unmodified:

http://stromberg.dnsalias.org/~dstromberg/Intro-to-Python/

Specifically, I mean the Writing code to run on Python 2.x and 3.x document.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] 2.x vs 3.x survey results

[Dan Stromberg]

Is there a better place to put this than:
http://stromberg.dnsalias.org/~strombrg/python-2.x-vs-3.x-survey/

Thanks.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.x vs 3.x survey results

[Dan Stromberg]

On Thu, Jan 2, 2014 at 1:34 PM, Antoine Pitrou solip...@pitrou.net wrote:
 On Thu, 2 Jan 2014 13:10:36 -0800
 Dan Stromberg drsali...@gmail.com wrote:
 Is there a better place to put this than:
 http://stromberg.dnsalias.org/~strombrg/python-2.x-vs-3.x-survey/

 Thank you for doing this!

My pleasure.

 If wiki.python.org supports file uploads, it may be the place for
 publishing the results.

I put it at https://wiki.python.org/moin/2.x-vs-3.x-survey , with a
link from https://wiki.python.org/moin/Python2orPython3 .  I put it in
the CategoryImplementations category.

The text I added to https://wiki.python.org/moin/Python2orPython3
reads Some people just don't want to use Python 3.x, which is their
prerogative. However, they are in the minority., where in the
minority is a link to the survey page.

Does anyone want to vet it before I tell more people where to find it?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.x vs 3.x survey results

[Dan Stromberg]

On Thu, Jan 2, 2014 at 3:20 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
 Antoine Pitrou solip...@pitrou.net writes:

 If wiki.python.org supports file uploads, it may be the place for
 publishing the results.

 Dan, can your reporting tool produce the report in HTML format (and
 plots as SVG images)? That would be IMO more suitable for uploading.

I believe people with a more expensive account than I paid for, have
access to an HTML version.  I don't know if the graphs are jpeg's or
what in that.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.x vs 3.x survey results

[Dan Stromberg]

I don't know much (if anything ^_^) about survey methodology.  I just
created a 9 question survey and tossed it at a few places that
Pythonistas hang out.

Does this look better?

https://wiki.python.org/moin/2.x-vs-3.x-survey

Thanks.


On Thu, Jan 2, 2014 at 5:45 PM, Gregory P. Smith g...@krypto.org wrote:
 Somewhere you need to describe the survey methodology, who was surveyed, how
 were they selected, etc.


 On Thu, Jan 2, 2014 at 2:54 PM, Dan Stromberg drsali...@gmail.com wrote:

 On Thu, Jan 2, 2014 at 1:34 PM, Antoine Pitrou solip...@pitrou.net
 wrote:
  On Thu, 2 Jan 2014 13:10:36 -0800
  Dan Stromberg drsali...@gmail.com wrote:
  Is there a better place to put this than:
  http://stromberg.dnsalias.org/~strombrg/python-2.x-vs-3.x-survey/
 
  Thank you for doing this!

 My pleasure.

  If wiki.python.org supports file uploads, it may be the place for
  publishing the results.

 I put it at https://wiki.python.org/moin/2.x-vs-3.x-survey , with a
 link from https://wiki.python.org/moin/Python2orPython3 .  I put it in
 the CategoryImplementations category.

 The text I added to https://wiki.python.org/moin/Python2orPython3
 reads Some people just don't want to use Python 3.x, which is their
 prerogative. However, they are in the minority., where in the
 minority is a link to the survey page.

 Does anyone want to vet it before I tell more people where to find it?
 ___
 Python-Dev mailing list
 Python-Dev@python.org
 https://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe:
 https://mail.python.org/mailman/options/python-dev/greg%40krypto.org


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fwd: Python 2.x and 3.x usage survey

[Dan Stromberg]

On Tue, Dec 31, 2013 at 1:50 AM, Paul Moore p.f.mo...@gmail.com wrote:
 On 31 December 2013 05:31, Dan Stromberg drsali...@gmail.com wrote:
 So far the results are looking good for 3.x.

 Where can the results be seen?

I don't think there's a publicly-available results page yet.  I'll
summarize them after more people have had a chance to fill it out.

I'm trying to get it onto planet python - that should help.  But I
created the blog post without a Python label initially, and added it
afterward - not sure if that'll work or not.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Fwd: Python 2.x and 3.x usage survey

[Dan Stromberg]

So far the results are looking good for 3.x.

-- Forwarded message --
From: Dan Stromberg drsali...@gmail.com
Date: Mon, Dec 30, 2013 at 1:56 PM
Subject: Python 2.x and 3.x usage survey
To: Python List python-l...@python.org


I keep hearing naysayers, nay saying about Python 3.x.

Here's a 9 question, multiple choice survey I put together about
Python 2.x use vs Python 3.x use.

I'd be very pleased if you could take 5 or 10 minutes to fill it out.

Here's the URL:
https://www.surveymonkey.com/s/N5N5PG2
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Hashes on same site as download?

[Dan Stromberg]

I may be missing something, but it seems the Python tarballs and hashes are
on the same host, and this is not an entirely good thing for security.

The way things are now, an attacker breaks into one host, doctors up a
tarball, changes the hashes in the same host, and people download without
noticing, even if they verify hashes.

If you put the hashes on a different host from the tarballs, the attacker
has to break into two machines.  In this scenario, the hashes add more
strength.

ISTR I first learned of this issue from an article by Bruce Schneier,
though I don't think it was in the context of Python.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Hashes on same site as download?

[Dan Stromberg]

On Mon, Oct 21, 2013 at 6:47 PM, Tim Delaney timothy.c.dela...@gmail.comwrote:

 On 22 October 2013 12:21, Dan Stromberg drsali...@gmail.com wrote:


 I may be missing something, but it seems the Python tarballs and hashes
 are on the same host, and this is not an entirely good thing for security.

 I was missing the gpg signing.  That's probably more effective than md5
anyway - at least, I hope we're not using gpg with md5 :)

Looking at the download pages in rapid-skim-mode, I saw the hashes and
ignored the text describing the use of gpg.  FWIW, I'm guessing a lot of
people do that.

The way things are now, an attacker breaks into one host, doctors up a
 tarball, changes the hashes in the same host, and people download without
 noticing, even if they verify hashes.

 If you put the hashes on a different host from the tarballs, the attacker
 has to break into two machines.  In this scenario, the hashes add more
 strength.


 I'm not a security expert, but I can't see how that gives any more
 security than the current system (I tried to find whatever article you're
 talking about, but failed). It doesn't matter if you provide downloads in
 one place and direct people to get the hashes from elsewhere. An attacker
 has no need to compromise the server where the hashes are stored - they
 only need to compromise the server that tells you where to get the
 downloads and hashes.


I don't see the original article anymore, but I believe it was in a
Crypto-gram newsletter several years ago.

The closest thing I found tonight was:
http://en.wikipedia.org/wiki/MD5#Applications
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Do you consider Python a 4GL? Why (not)?

[Dan Stromberg]

On Tue, Jun 4, 2013 at 4:53 PM, Carlos Nepomuceno 
carlosnepomuc...@outlook.com wrote:

 Do you consider Python a 4GL? Why (not)?


By the wikipedia definition of 4GL and 5GL, I'd say Python is neither.  And
it's not a VHLL either, again according to the wikipedia definition.  But
IMO it is too high level to be a traditional 3GL too.

Perhaps Scripting language is the best general category we have that
Python fits into.  But I hope not.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] New FreeBSD 10.0-CURRENT buildbot

[Dan Stromberg]

On Sun, Jun 2, 2013 at 12:51 PM, Carlos Nepomuceno 
carlosnepomuc...@outlook.com wrote:

 
  Date: Sun, 2 Jun 2013 15:12:43 +1000
  From: koobs.free...@gmail.com
  To: python-dev@python.org
  Subject: [Python-Dev] New FreeBSD 10.0-CURRENT buildbot
 [...]
  koobs-freebsd10-amd64 (clang is default here)


 Does CPython code compiled with clang runs faster than gcc?

 Why did you chose clang? Any benchmarks? Any benefits?


Clang is sometimes favored over gcc for its non-GPL license; I believe the
FreeBSD project sees this as an important issue.

In general, the more C compilers a piece of C code compiles on, the fewer
bugs are left in it, because different C compilers tend to catch different
problems - even with cranked up warnings.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

[Dan Stromberg]

On Sat, May 18, 2013 at 11:41 PM, Raymond Hettinger 
raymond.hettin...@gmail.com wrote:


 On May 14, 2013, at 9:39 AM, Gregory P. Smith g...@krypto.org wrote:

 Bad: doctests.


 I'm hoping that core developers don't get caught-up in the doctests are
 bad meme.


Don't doctests intended for CPython not work on Jython, Pypy, IronPython...

I've been avoiding them for this reason.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Ctypes and the stdlib (was Re: LZMA compression support in 3.3)

[Dan Stromberg]

On Tue, Aug 30, 2011 at 10:05 AM, Guido van Rossum gu...@python.org wrote:

 On Tue, Aug 30, 2011 at 9:49 AM, Martin v. Löwis mar...@v.loewis.de
 wrote:
  The problem lies with the PyPy backend -- there it generates ctypes
 code, which means that the signature you declare to Cython/Pyrex must
 match the *linker* level API, not the C compiler level API. Thus, if
 in a system header a certain function is really a macro that invokes
 another function with a permuted or augmented argument list, you'd
 have to know what that macro does. I also don't see how this would
 work for #defined constants: where does Cython/Pyrex get their value?
 ctypes doesn't have their values.

 So, for PyPy, a solution based on Cython/Pyrex has many of the same
 downsides as one based on ctypes where it comes to complying with an
 API defined by a .h file.


It's certainly a harder problem.

For most simple constants, Cython/Pyrex might be able to generate a series
of tiny C programs with which to find CPP symbol values:

#include file1.h
...
#include filen.h

main()
{
printf(%d, POSSIBLE_CPP_SYMBOL1);
}

...and again with %f, %s, etc.  The typing is quite a mess, and code
fragments would probably be impractical.  But since the C Preprocessor is
supposedly turing complete, maybe there's a pleasant surprise waiting there.

But hopefully clang has something that'd make this easier.

SIP's approach of using something close to, but not identical to, the .h's
sounds like it might be pretty productive - especially if the derivative of
the .h's could be automatically derived using a python script, with minor
tweaks to the inputs on .h upgrades.  But sip itself is apparently C++-only.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Should we move to replace re with regex?

[Dan Stromberg]

On Fri, Aug 26, 2011 at 8:47 PM, Steven D'Aprano st...@pearwood.infowrote:

 Antoine Pitrou wrote:

 On Fri, 26 Aug 2011 17:25:56 -0700
 Dan Stromberg drsali...@gmail.com wrote:

 If you add regex as import regex, and the new regex module doesn't work

 out, regex might be harder to get rid of.  from __future__ import is an
 established way of trying something for a while to see if it's going to
 work.


 That's an interesting idea. This way, integrating the new module would
 be a less risky move, since if it gives us too many problems, we could
 back out our decision in the next feature release.


 I'm not sure that's correct. If there are differences in either the
 interface or the behaviour between the new regex and re, then reverting will
 be a pain regardless of whether you have:

 from __future__ import re
 re.compile(...)

 or

 import regex
 regex.compile(...)


 Either way, if the new regex library goes away, code will break, and fixing
 it may not be easy.


You're talking technically, which is important, but wasn't what I was
suggesting would be helped.

Politically, and from a marketing standpoint, it's easier to withdraw a
feature you've given with a Play with this, see if it works for you
warning.

Have then been any __future__ features that were added provisionally?


I can't either, but ISTR hearing that from __future__ import was started
with such an intent.  Irrespective, it's hard to import something from
future without at least suspecting that you're on the bleeding edge.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Should we move to replace re with regex?

[Dan Stromberg]

On Sat, Aug 27, 2011 at 9:19 AM, Guido van Rossum gu...@python.org wrote:

 On Fri, Aug 26, 2011 at 11:01 PM, Dan Stromberg drsali...@gmail.com
 wrote:
 [Steven]
  Have then been any __future__ features that were added provisionally?
 
  I can't either, but ISTR hearing that from __future__ import was started
  with such an intent.  Irrespective, it's hard to import something from
  future without at least suspecting that you're on the bleeding edge.

 No, this was not the intent of __future__. The intent is that a
 feature is desirable but also backwards incompatible (e.g. introduces
 a new keyword) so that for 1 (sometimes more) releases we require the
 users to use the __future__ import.

 There was never any intent to use __future__ for experimental
 features. If we want that maybe we could have from __experimental__
 import whatever.

 OK.  So what -is- the purpose of from __future__ import?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Should we move to replace re with regex?

[Dan Stromberg]

On Sat, Aug 27, 2011 at 9:53 AM, Brian Curtin brian.cur...@gmail.comwrote:

 On Sat, Aug 27, 2011 at 11:48, Dan Stromberg drsali...@gmail.com wrote:

 No, this was not the intent of __future__. The intent is that a
 feature is desirable but also backwards incompatible (e.g. introduces
 a new keyword) so that for 1 (sometimes more) releases we require the
 users to use the __future__ import.

 There was never any intent to use __future__ for experimental
 features. If we want that maybe we could have from __experimental__
 import whatever.

 OK.  So what -is- the purpose of from __future__ import?


 It's in the first paragraph.


I disagree.  The first paragraph says this has something to do with new
keywords.  It doesn't appear to say what we expect users to -do- with it.
Both are important.

Is it You'd better try this, because it's going in eventually.  If you
don't try it out before it becomes default behavior, you have no right to
complain?

And if people do complain, what are python-dev's options?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] LZMA compression support in 3.3

[Dan Stromberg]

On Sat, Aug 27, 2011 at 9:04 AM, Nick Coghlan ncogh...@gmail.com wrote:

 On Sun, Aug 28, 2011 at 1:58 AM, Nadeem Vawda nadeem.va...@gmail.com
 wrote:
  On Sat, Aug 27, 2011 at 5:52 PM, Nick Coghlan ncogh...@gmail.com
 wrote:
  It's acceptable for the Python version to use ctypes in the case of
  wrapping an existing library, but the Python version should still
  exist.
 
  I'm not too sure about that - PEP 399 explicitly says that using ctypes
 is
  frowned upon, and doesn't mention anywhere that it should be used in this
  sort of situation.

 Note to self: do not comment on python-dev at 2 am, as one's ability
 to read PEPs correctly apparently suffers :)

 Consider my comment withdrawn, you're quite right that PEP 399
 actually says this is precisely the case where an exemption is a
 reasonable idea. Although I believe it's likely that PyPy will wrap it
 with ctypes anyway :)


I'd like to better understand why ctypes is (sometimes) frowned upon.

Is it the brittleness?  Tendency to segfault?

If yes, is there a way of making ctypes less brittle - say, by carefully
matching it against a specific version of a .so/.dll before starting to make
heavy use of said .so/.dll?

FWIW, I have a partial implementation of a module that does xz from Python
using ctypes.  It only does in-memory compression and decompression (not
stream compression or decompression to or from a file), because that was all
I needed for my current project, but it runs on CPython 2.x, CPython 3.x,
and PyPy.  I don't think it runs on Jython, but I've not looked at that
carefully - my code falls back on subprocess if ctypes doesn't appear to be
all there.

It's at http://stromberg.dnsalias.org/svn/xz_mod/trunk/xz_mod.py
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] LZMA compression support in 3.3

[Dan Stromberg]

On Sat, Aug 27, 2011 at 1:21 PM, Martin v. Löwis mar...@v.loewis.dewrote:

  I'd like to better understand why ctypes is (sometimes) frowned upon.
 
  Is it the brittleness?  Tendency to segfault?

 That, and Python should work completely if ctypes is not available.


What are the most major platforms ctypes doesn't work on?

It seems like there should be some way of coming up with an xml file
describing the types of the various bits of data and formal arguments -
perhaps using gccxml or something like it.

 FWIW, I have a partial implementation of a module that does xz from
  Python using ctypes.

 So does it work on Sparc/Solaris? On OpenBSD? On ARM-Linux? Does it
 work if the xz library is installed into /opt/sfw/xz?


So far, I've only tried it on a couple of Linuxes and Cygwin.  I intend to
try it on a large number of *ix variants in the future, including OS/X and
Haiku.  I doubt I'll test OpenBSD, but I'm likely to test on FreeBSD and
Dragonfly again.

With regard to /opt/sfw/xz, if ctypes.util.find_library(library) is smart
enough to look there, then yes, xz_mod should find libxz there.

On Cygwin, ctypes.util.find_library() wasn't smart enough to find a Cygwin
DLL, so I coded around that.  But it finds the library OK on the Linuxes
I've tried so far.

(This is part of a larger project, a backup program.  The backup program has
been tested on a large number of OS's, but I've not done another broad round
of testing yet since adding the ctypes+xz code)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] LZMA compression support in 3.3

[Dan Stromberg]

On Sat, Aug 27, 2011 at 2:38 PM, Nadeem Vawda nadeem.va...@gmail.comwrote:

 On Sat, Aug 27, 2011 at 10:41 PM, Dan Stromberg drsali...@gmail.com
 wrote:
  It seems like there should be some way of coming up with an xml file
  describing the types of the various bits of data and formal arguments -
  perhaps using gccxml or something like it.

 The problem is that you would need to do this check at runtime, every time
 you load up the library - otherwise, what happens if the user upgrades
 their installed copy of liblzma? And we can't expect users to have the
 liblzma headers installed, so we'd have to try and figure out whether the
 library was ABI-compatible from the shared object alone; I doubt that this
 is even possible.


I was thinking about this as I was getting groceries a bit ago.

Why -can't- we expect the user to have liblzma headers installed?  Couldn't
it just be a dependency in the package management system?

BTW, gcc-xml seems to be only for C++ (?), but long ago, around the time
people were switching from KR to Ansi C, there were programs like
mkptypes that could parse a .c/.h and output prototypes.  It seems we
could do something like this on module init.

IMO, we really, really need some common way of accessing C libraries that
works for all major Python variants.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] LZMA compression support in 3.3

[Dan Stromberg]

On Sat, Aug 27, 2011 at 3:26 PM, Antoine Pitrou solip...@pitrou.net wrote:

 On Sat, 27 Aug 2011 15:14:15 -0700
 Dan Stromberg drsali...@gmail.com wrote:

  On Sat, Aug 27, 2011 at 2:38 PM, Nadeem Vawda nadeem.va...@gmail.com
 wrote:
 
   On Sat, Aug 27, 2011 at 10:41 PM, Dan Stromberg drsali...@gmail.com
   wrote:
It seems like there should be some way of coming up with an xml file
describing the types of the various bits of data and formal arguments
 -
perhaps using gccxml or something like it.
  
   The problem is that you would need to do this check at runtime, every
 time
   you load up the library - otherwise, what happens if the user upgrades
   their installed copy of liblzma? And we can't expect users to have the
   liblzma headers installed, so we'd have to try and figure out whether
 the
   library was ABI-compatible from the shared object alone; I doubt that
 this
   is even possible.
  
 
  I was thinking about this as I was getting groceries a bit ago.
 
  Why -can't- we expect the user to have liblzma headers installed?
  Couldn't
  it just be a dependency in the package management system?

 Package managers, under Linux, often split development files (headers,
 etc.) from runtime binaries.


Well, uh, yeah.  Not sure what your point is.
1) We could easily work with the dev / nondev distinction by taking a
dependency on the -dev version of whatever we need, instead of the nondev
version.
2) It's a rather arbitrary distinction that's being drawn between dev and
nondev today.  There's no particular reason why the line couldn't be drawn
somewhere else.


 Also, under Windows, most users don't have development stuff installed
 at all.

Yes...  But if the nature of what development stuff is were to change,
they'd have different stuff.

Also, we wouldn't have to parse the .h's every time a module is loaded - we
could have a timestamp file (or database) indicating when we last parsed a
given .h.

Also, we could query the package management system for the version of lzma
that's currently installed on module init.

Also, we could include our own version of lzma.  Granted, this was a mess
when zlib needed to be patched, but even this one might be worth it for the
improved library unification across Python implementations.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] LZMA compression support in 3.3

[Dan Stromberg]

On Sat, Aug 27, 2011 at 4:27 PM, Antoine Pitrou solip...@pitrou.net wrote:


 Sure. Now please convince Linux distributions first, because this
 particular subthread is going nowhere.


I hope you're not a solipsist.

Anyway, if the mere -discussion- of embracing a standard and safe way of
making C libraries callable from all the major Python implementations is
going nowhere before the discussion has even gotten started, I fear for
Python's future.

Repeat aloud to yourself: Python != CPython.  Python != CPython.  Python !=
CPython.

Has this topic been discussed to death?  If so, then say so.  It's rude to
try to kill the thread summarily before it gets started, sans discussion,
sans explanation, sans commentary on whether new additions to the topic have
surfaced or not.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] LZMA compression support in 3.3

[Dan Stromberg]

On Sat, Aug 27, 2011 at 4:27 PM, Antoine Pitrou solip...@pitrou.net wrote:

 On Sat, 27 Aug 2011 16:19:01 -0700
 Dan Stromberg drsali...@gmail.com wrote:
  2) It's a rather arbitrary distinction that's being drawn between dev and
  nondev today.  There's no particular reason why the line couldn't be
 drawn
  somewhere else.

 Sure. Now please convince Linux distributions first, because this
 particular subthread is going nowhere.


Interesting.  You seem to want to throw an arbitrary barrier between Python,
the language, and accomplishing something important for said language.

Care to tell me why I'm wrong?  I'm all ears.

I'll note that you've deleted:

 1) We could easily work with the dev / nondev distinction by
 taking a dependency on the -dev version of whatever we need,
 instead of the nondev version.

...which makes it more than apparent that we needn't convince Linux
distributors of #2, which you seem to prefer to focus on.

Why was it in your best interest to delete #1, without even commenting on
it?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] LZMA compression support in 3.3

[Dan Stromberg]

On Sat, Aug 27, 2011 at 8:57 PM, Guido van Rossum gu...@python.org wrote:

 On Sat, Aug 27, 2011 at 3:14 PM, Dan Stromberg drsali...@gmail.com
 wrote:
  IMO, we really, really need some common way of accessing C libraries that
  works for all major Python variants.

 We have one. It's called writing an extension module.


And yet Cext's are full of CPython-isms.

I've said in the past that Python has been lucky in that it had only a
single implementation for a long time, but still managed to escape becoming
too defined by the idiosyncrasies of that implementation - that's quite
impressive, and is probably our best indication that Python has had
leadership with foresight.  In the language proper, I'd say I still believe
this, but Cext's are sadly not a good example.


 ctypes is a crutch because it doesn't realistically have access to the
 header files.


Well, actually, header files are pretty easy to come by.  I bet you've
installed them yourself many times.  In fact, you've probably even
automatically brought some of them in via a package management system of one
form or another without getting your hands dirty.

As a thought experiment, imagine having a ctypes configuration system that
looks around a computer for .h's and .so's (etc) with even 25% of the effort
expended by GNU autoconf.  Instead of building the results into a bunch of
.o's, the results are saved in a .ct file or something.  If you build-in
some reasonable default locations to look in, plus the equivalent of some
-I's and -L's (and maybe -rpath's) as needed, you probably end up with a
pretty comparable system.

(typedef's might be a harder problem - that's particularly worth discussing,
IMO - your chance to nip this in the bud with a reasoned explanation why
they can't be handled well!)

It's a fine crutch for PyPy, which doesn't have much of
 an alternative.


Wait - a second ago I thought I was to believe that C extension modules were
the one true way of interfacing with C code across all major
implementations?  Are we perhaps saying that CPython is the major
implementation, and that we want it to stay that way?

I personally feel that PyPy has arrived as a major implementation.  The
backup program I've been writing in my spare time runs great on PyPy (and
the CPython's from 2.5.x, and pretty well on Jython).  And PyPy has been
maturing very rapidly ('just wish they'd do 3.x!).

It's also a fine crutch for people who need something
 to run *now*. It's a horrible strategy for the standard library.


I guess I'm coming to see this as dogma.

If ctypes is augmented with type information and/or version information and
where to find things, wouldn't it Become safe and convenient?  Or do you
have other concerns?

Make a list of things that can go wrong with ctypes modules.  Now make a
list of things that can wrong with C extension modules.  Aren't they really
pretty similar - missing .so, .so in a weird place, and especially: .so with
a changed interface?  C really isn't a very safe language - not like
http://en.wikipedia.org/wiki/Turing_%28programming_language%29 or
something.  Perhaps it's a little easier to mess things up with ctypes today
(a recompile doesn't fix, or at least detect, as many problems), but isn't
it at least worth Thinking about how that situation could be improved?

If you have a better proposal please do write it up. But so far you
 are mostly exposing your ignorance and insisting dramatically that you
 be educated.


I'm not sure why you're trying to avoid having a discussion.  I think it's
premature to dive into a proposal before getting other people's thoughts.
Frankly, 100 people tend to think better than one - at least, if the 100
people feel like they can talk.

I'm -not- convinced ctypes are the way forward.  I just want to talk about
it - for now.  ctypes have some significant advantages - if we can find a
way to eliminate and/or ameliorate their disadvantages, they might be quite
a bit nicer than Cext's.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Should we move to replace re with regex?

[Dan Stromberg]

On Fri, Aug 26, 2011 at 2:45 PM, Guido van Rossum gu...@python.org wrote:

 ...but on second thought I wonder if maybe regex is
 mature enough to replace re in Python 3.3.


I agree that the move from regex to re was kind of painful.

It seems someone should merge the unit tests for re and regex, and apply the
merged result to each for the sake of comparison.  There might also be a
need to expand the merged result to include new things.

Then there probably should be a from __future__ import for a while.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Should we move to replace re with regex?

[Dan Stromberg]

On Fri, Aug 26, 2011 at 5:08 PM, Antoine Pitrou solip...@pitrou.net wrote:

 On Fri, 26 Aug 2011 15:48:42 -0700
 Dan Stromberg drsali...@gmail.com wrote:
 
  Then there probably should be a from __future__ import for a while.

 If you are willing to use a from __future__ import, why not simply

import regex as re

 ? We're not Perl, we don't have built-in syntactic support for regular
 expressions.

 Regards


If you add regex as import regex, and the new regex module doesn't work
out, regex might be harder to get rid of.  from __future__ import is an
established way of trying something for a while to see if it's going to
work.

EG: from __future__ import re, where re is really the new module.

But whatever.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] hard linking executables

[Dan Stromberg]

It's been suggested that *ix has hardlinks because someone thought up
hardlinks before someone thought up symlinks - IOW, there are those who
suggest that if people had added symlinks first, no one would've bothered
adding hardlinks.

Symlinks are almost always more flexible, and almost always more clear.

The main counterexample seems to be rsync-based backup systems, that will
hardlink identical files of a given pathname.  But that seems to be a bit of
a mess when it comes time to transfer such a backup from one filesystem to
another.

On Tue, Jul 26, 2011 at 3:32 PM, Barry Warsaw ba...@python.org wrote:

 On Jul 27, 2011, at 12:19 AM, Antoine Pitrou wrote:

 Ok, apparently the decision to make hard links for executables dates at
 least back to:

 That still doesn't explain *why* hardlinks were originally chosen instead
 of
 symlinks.  In the absence of any other compelling argument against it, I
 think
 they should all consistently be symlinks.  I don't see any Ubuntu or Debian
 (where /usr/bin/python3 - python3.2) bug reports indicating any problems,
 and
 I haven't experienced any issues with it personally.

 changeset:   16221:588691f806f4
 branch:  legacy-trunk
 user:Neil Schemenauer nasch...@enme.ucalgary.ca
 date:Wed Jan 24 17:11:43 2001 +
 files:   Makefile.pre.in
 description:
 Flat makefile based on toplevel Makefile.in and makefiles in build
 subdirectories.  Those other makefiles will go away eventually.
 
 [...]
 
 +# Install the interpreter (by creating a hard link to python$(VERSION))
 +bininstall:altbininstall
 +   -if test -f $(BINDIR)/$(PYTHON); \
 +   then rm -f $(BINDIR)/$(PYTHON); \
 +   else true; \
 +   fi
 +   (cd $(BINDIR); $(LN) python$(VERSION)$(EXEEXT) python$(EXEEXT))
 +

 -Barry

 ___
 Python-Dev mailing list
 Python-Dev@python.org
 http://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe:
 http://mail.python.org/mailman/options/python-dev/drsalists%40gmail.com


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] hard linking executables

[Dan Stromberg]

On Wed, Jul 27, 2011 at 2:37 PM, Ben Finney ben+pyt...@benfinney.id.auwrote:

 Dan Stromberg drsali...@gmail.com writes:

  It's been suggested that *ix has hardlinks because someone thought up
  hardlinks before someone thought up symlinks - IOW, there are those who
  suggest that if people had added symlinks first, no one would've bothered
  adding hardlinks.

 Well, that suggestion is faulty. It ignores the fact that *all* ordinary
 files on Unix are hard links. Any ordinary file entry in a directory is
 a hard link to the file's data.


Not really.  Whether hard links is supported is mostly a matter of what
filesystem you are using - in modern times.  It's true that filesystems with
complete POSIX semantics probably all support hardlinks, but that's far from
every file on any given *ix.  And of course, POSIX doesn't appear to have
been created until the late 1990's.


 The “hard links” capability, therefore, isn't something that was added;
 it's fundamental to Unix filesystems from their inception.


Hard linking was reportedly in Unix Version 1, but I see nothing indicating
it was in the original Unics of 1969.  Then again, I don't see much of
anything on the net about what was and wasn't in Unics.


 The ‘ln’ command adds *additional* hard links to an existing file's
 data; but, once added, they're exactly the same as any other ordinary
 file entry.


Well, if you're in a filesystem that supports hardlinking anyway.
Supporting that isn't inherent.  It requires some sort of on-disk
representation for persistence, and not all filesystems support that.


  Symlinks are almost always more flexible, and almost always more
  clear.

 Yet many tools don't work as expected with symbolic links which will
 work with an ordinary file (a “hard link”). One can argue that such
 tools are to that extent buggy, but symbolic links produce deliberately
 different behaviour which is sometimes not what one needs.


Please recall that I was paraphrasing someone saying that hardlinks were
seldom better, not never better.  I don't know that there's anything in your
post that addresses that.

It's much easier to imagine a system with no hardlinks, than to imagine a
system with no symlinks.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Compiling Python 3.2 on Cygwin fails

[Dan Stromberg]

On Tue, Jul 5, 2011 at 7:25 AM, David Robinow drobi...@gmail.com wrote:


  Cygwin is not really a supported platform.

...

 [Ultimately somebody with an
 interest in cygwin will need to get active in python development. I've
 been meaning to do this but life gets in the way.]


I was bitten by the lack of Cygwin support in 3.2 as well.

IMO,  python-dev needs continuous integration on a build farm that includes
representative platforms.  Most of the machines in the farm could be
virtualboxes.

I don't think the problem is so much that the right people haven't gotten
involved, as that the currently-involved people don't know when they're
breaking something for someone else due to the lack of continuous
integration.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Compiling Python 3.2 on Cygwin fails

[Dan Stromberg]

On Tue, Jul 5, 2011 at 12:18 PM, Brian Curtin brian.cur...@gmail.comwrote:

 On Tue, Jul 5, 2011 at 14:12, Dan Stromberg drsali...@gmail.com wrote:


 On Tue, Jul 5, 2011 at 7:25 AM, David Robinow drobi...@gmail.com wrote:


  Cygwin is not really a supported platform.

 ...

 [Ultimately somebody with an
 interest in cygwin will need to get active in python development. I've
 been meaning to do this but life gets in the way.]


 I was bitten by the lack of Cygwin support in 3.2 as well.

 IMO,  python-dev needs continuous integration on a build farm that
 includes representative platforms.  Most of the machines in the farm could
 be virtualboxes.

 I don't think the problem is so much that the right people haven't gotten
 involved, as that the currently-involved people don't know when they're
 breaking something for someone else due to the lack of continuous
 integration.


 We've had that for some time now: http://www.python.org/dev/buildbot/


Good to know.  Apologies for my incorrect assumption.  Where do the e-mail
notifications of build and/or test failures go?

Shouldn't Cygwin be represented here?  I don't see it in the list of builds.

Some shops have a policy that nothing gets merged into trunk unless it's
passing critical automated tests...  Would that work here?

There are several issues on the bug tracker about cygwin build issues, but
 to my knowledge, none of them have included successful patches.


I think you'll find that most people using Cygwin would rather be working on
some other OS, but are forced to use Windows for policy reasons.  It's
remains a rather significant need in many cases.

How does the buildbot initiate builds?  ssh?  Happily Cygwin mostly allows
sshd (as long as you don't need a CIFS share or something).

Native Windows builds do appear to be represented.  Is there any reason not
to set up a buildbot for Cygwin on the same (virtual?) hardware?

I'm inclined to believe that whoever rearranged the shared object stuff in
CPython 3.x's build system would've been more careful if they'd had feedback
about what it was doing to Cygwin.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Compiling Python 3.2 on Cygwin fails

[Dan Stromberg]

On Tue, Jul 5, 2011 at 1:00 PM, Brian Curtin brian.cur...@gmail.com wrote:

 On Tue, Jul 5, 2011 at 14:41, Dan Stromberg drsali...@gmail.com wrote:


 On Tue, Jul 5, 2011 at 12:18 PM, Brian Curtin brian.cur...@gmail.comwrote:

 On Tue, Jul 5, 2011 at 14:12, Dan Stromberg drsali...@gmail.com wrote:


 On Tue, Jul 5, 2011 at 7:25 AM, David Robinow drobi...@gmail.comwrote:


  Cygwin is not really a supported platform.

 ...

 [Ultimately somebody with an
 interest in cygwin will need to get active in python development. I've
 been meaning to do this but life gets in the way.]


 I was bitten by the lack of Cygwin support in 3.2 as well.

 IMO,  python-dev needs continuous integration on a build farm that
 includes representative platforms.  Most of the machines in the farm could
 be virtualboxes.

 I don't think the problem is so much that the right people haven't
 gotten involved, as that the currently-involved people don't know when
 they're breaking something for someone else due to the lack of continuous
 integration.


 We've had that for some time now: http://www.python.org/dev/buildbot/


 Good to know.  Apologies for my incorrect assumption.  Where do the e-mail
 notifications of build and/or test failures go?


 There might be an RSS feed or something, but I don't think there's any
 email notification. #python-dev on IRC receives live failure info. Other
 than that, you'd just have to look at one of the views of the fleet to see
 which build slaves are failing.


Am I correct in assuming that stable buildbots are required to be
reasonably functional before a release is tagged?


 Shouldn't Cygwin be represented here?  I don't see it in the list of
 builds.


 Probably, but it isn't represented because no one contributed a build slave
 for it. I know some of the other Windows build slave operators use Cygwin to
 some degree, but I'm not sure if anyone has looked into actually setting up
 a build slave for it.


I see.


 Some shops have a policy that nothing gets merged into trunk unless it's
 passing critical automated tests...  Would that work here?


 We don't make much use of branching, but that would work if we did. If no
 one is actively contributing work on the Cygwin build then I don't see us
 holding up work in order to figure out any Cygwin-specific issues.


I might suggest that doing so (using branching, keeping trunk stable) might
be of benefit, especially with a DVCS.



 There are several issues on the bug tracker about cygwin build issues, but
 to my knowledge, none of them have included successful patches.


 I think you'll find that most people using Cygwin would rather be working
 on some other OS, but are forced to use Windows for policy reasons.  It's
 remains a rather significant need in many cases.


 I don't disagree with that, but if there's no one contributing Cygwin
 patches then it will probably just die off and we'll have situations like
 the current one where it doesn't build. A great majority of the contributing
 developers are on UNIX-based systems with no access to Windows. A small
 handful, myself included, are Windows users, but I don't think any of us use
 Cygwin (I don't).


I see.

Is there a python.org resource for setting up mailing lists - say, for a
python-cygwin mailing list?



 Native Windows builds do appear to be represented.  Is there any reason not
 to set up a buildbot for Cygwin on the same (virtual?) hardware?


 Besides the time and effort needed to set it up and occasionally look over
 it, no. We'd have to have a successfully compiling Cygwin build before we
 think about adding a build slave for it.


That makes sense.


 I wouldn't be opposed to hosting this myself, but I need to steal some time
 and get my Windows 2008 build slave back to some form of a functional system
 - it has been up and down for a few months now. If someone else is
 interested, go ahead.


I might contribute some elbow grease if someone could get me VNC access to a
suitable Windows server.

BTW, is there someone available who is familiar with the meanings of the
various shared object-related make symbols?  I glanced at them and didn't
find their naming astonishingly clear - seems like something to document,
or...  maybe it already is, and I just haven't seen where it is yet.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: Add NEWS and whatsnew entries for the packaging module

[Dan Stromberg]

On Fri, Jun 3, 2011 at 3:29 PM, Tres Seaver tsea...@palladion.com wrote:

  Even for Python 2.4, really? Do you really need to support this old
 Python


 Yes.  Many projects distribute packages to folks still using 2.4.


Supporting detail: I recently installed the latest CentOS, 5.6, and found
that it still Ships with CPython 2.4.

I installed a CPython 3.2 in /usr/local almost immediately, but I can see
how some might want 2.4 support yet.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Linus on garbage collection

[Dan Stromberg]

On Fri, May 6, 2011 at 7:04 AM, Neal Becker ndbeck...@gmail.com wrote:

 http://gcc.gnu.org/ml/gcc/2002-08/msg00552.html


Of course, a generational GC improves locality of reference.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] running/stepping python backwards

[Dan Stromberg]

On Mon, May 2, 2011 at 1:49 PM, Terry Reedy tjre...@udel.edu wrote:

  (Please reply to me directly.)

 I did this time, but you should not expect that when posting to a public
 list.


Actually, this is not only appropriate on some lists, on some lists one is
actually strongly discouraged from doing anything else.

EG: sun-managers, where replies are expected to be private, and the
originator of the thread is expected to collect all (private) replies and
summarize them, to keep the list traffic low and the S/N ratio high.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com