Re: Pyhon 2.x or 3.x, which is faster?

[Chris Angelico]

On Thu, Mar 10, 2016 at 6:30 PM, Mark Lawrence  wrote:
>>  From what I've seen, a lot of software can't get [Unicode] right anyway.
>>
>
> Are you referring to PEP393 having taken notice of the RUE?

Even with PEP 393, there's no guarantee that a Python program will get
Unicode right. The bytes/text split in Python 3 is a huge help, but
proper handling of the entire Unicode range implies more than simply
being able to represent all characters (although that's a critical
prerequisite). There are design considerations with case folding (tip:
it's easiest and safest to be case sensitive), collation/sorting (tip:
it's impossible to be perfect unless you know which language is
involved), text directionality (you probably know that Arabic is
written right-to-left, but are you aware that there are also
characters with "weak" directionality, distinct from those with
"neutral" directionality?) and so on, plus a bunch of relatively
straight-forward coding considerations (eg comparing two strings for
equality generally requires NFC/NFC normalization, and might require
NFKC/NFKD), which a number of programs still don't get right. PEP 393
actually isn't very much about correctness; a "wide build" of pre-3.3
Python has the correct behaviour, but is wasteful with memory. By
removing the temptation to conserve memory using UTF-16, PEP 393 did
improve correctness on Windows, but its main focus is on memory
efficiency (and thus performance, thanks to cache locality).

But hey. Just being able to represent all characters is probably about
95% of Unicode correctness. The rest is the little stuff.

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

Re: Text input with keyboard, via input methods (was: turtle ??)

[Rustom Mody]

On Thursday, March 10, 2016 at 12:59:10 PM UTC+5:30, Ben Finney wrote:
> Marko Rauhamaa  writes:
> 
> > BTW, typing any useful Unicode character is a major unsolved problem.
> 
> You typed a good number of Unicode characters in that sentence alone.
> ASCII is a simple subset of Unicode.
> 
> I suppose you meant to refer to typing some character not mapped to a
> single keystroke on a US-English keyboard kayout.
> 
> You're right, that is a major problem.
> 
> As for how solved it is, that depends on what you're hoping for as a
> solution.
> 
> The conventional solution, which I find to be quite useful for typing
> characters from a great many different writing systems, is an
>  customised to
> particular writing systems.
> 
> My primary input method is one which lets me type typical English text
> and also easily input a broad range of useful characters with a few
> mnenonic two- or three-key sequences.
> 
> > I have created this text file that contains a lot of unicode
> > characters with their code points. Every once in a while I have to
> > open the file and copy and paste a character to, say, a Usenet
> > posting. Cumbersome but necessary.
> 
> Hopefully your operating system has a good input method system, with
> many input methods available to choose from. May you find a decent
> default there.

I believe that these discussions would be useful (and the current state
of input methods better-ed if we distinguish different levels of input-methods.

Basically ranging from low-setup, hi-perchar cost to hi-setup low-perchar cost

At the one extreme we have
use google, hunt around, cut-paste

At the other use a special hardware keyboard
[I believe Steven had sometime showed something like this
https://plus.google.com/102786751626732213960/posts/2uJzHw1JHeN?pid=5802841322291932386=102786751626732213960
]

In between these two extremes we have many possibilities
- ibus/gchar etc
- compose key
- alternate keyboard layouts

Using all these levels judiciously seems to me a good idea...
-- 
https://mail.python.org/mailman/listinfo/python-list

Installing ibm_db package on Windows 7, 64-bit problem

[Alexander Shmugliakov]

Hello, has anybody successfully installed ibm_db package in the 32-bit Python 
3.5.0 environment? This is the error messages I'm receiving:
I know that the message about vcvarsall.bat is related to the Visual Studio 
configuration -- I don't have it on my computer. I have no 64-bit IBM Data 
Server Driver installed on my machine. Any help will be *greatly* appreciated.

'--'
C:\Program Files (x86)\Python 3.5>easy_install ibm_db
Searching for ibm-db
Reading https://pypi.python.org/simple/ibm_db/
Best match: ibm-db 2.0.6
Downloading 
https://pypi.python.org/packages/source/i/ibm_db/ibm_db-2.0.6.tar.gz#md5=f6b80e1489167a141ebf8978c37ca398
Processing ibm_db-2.0.6.tar.gz
Writing 
C:\Users\shmuglak\AppData\Local\Temp\easy_install-yijpttuo\ibm_db-2.0.6\setup.cfg
Running ibm_db-2.0.6\setup.py -q bdist_egg --dist-dir 
C:\Users\shmuglak\AppData\Local\Temp\easy_install-yijpttuo\ibm_db-
2.0.6\egg-dist-tmp-np3lk_6i
Detected 32-bit Python
C:\Users\shmuglak\AppData\Local\Temp\easy_install-yijpttuo\ibm_db-2.0.6\setup.py:204:
 UserWarning: Detected usage of IBM
 Data Server Driver package. Ensure you have downloaded 32-bit package of 
IBM_Data_Server_Driver and retry the ibm_db module install

  warnings.warn(notifyString)
warning: no files found matching 'README'
warning: no files found matching '*' under directory 'clidriver'
warning: no files found matching '*' under directory 'ibm_db_dlls'
error: Setup script exited with error: Unable to find vcvarsall.bat
'--'

My environment:
Windows 7 Professional, SP1
Python:
Python 3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:16:59) [MSC v.1900 32 bit 
(Intel)] on win32 

IBM IBM Data Server Driver Package:
Client Package Type   : IBM Data Server Driver Package
Client Version (level/bit): DB2 v10.5.0.420 (s130528/32-bit)
Client Platform   : NT
Install/Instance Path : C:\PROGRA~2\IBM\IBMDAT~1

Common App Data Path  : C:\ProgramData\IBM\DB2\IBMDBCL1
DB2DSDRIVER_CFG_PATH value: C:\ProgramData\IBM\DB2\IBMDBCL1\cfg
db2dsdriver.cfg Path  : \cfg\db2dsdriver.cfg
DB2CLIINIPATH value   : C:\ProgramData\IBM\DB2\IBMDBCL1\cfg
db2cli.ini Path   : \cfg\db2cli.ini
db2diag.log Path  : \db2diag.log

==
List of all IBM Data Server client packages on the current workstation:


Copyname  Version Package Language Installed-Location

IBMDBCL1[C,D] 10.5.00 DSD ALL_LANG C:\Program Files (x86)\IBM\IBM DATA 
SERVER DRIVER

 DSD: IBM Data Server Driver Package

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

Re: Pyhon 2.x or 3.x, which is faster?

[Ben Finney]

Mark Lawrence  writes:

> Yes I am, as you appear to know squat.

Cut it out, please. This is now bullying.

Bart is interested in things that don't interest you; if you can't
engage him cordially, please desist.

-- 
 \ “Pinky, are you pondering what I'm pondering?” “I think so, |
  `\ Brain, but what kind of rides do they have in Fabioland?” |
_o__)   —_Pinky and The Brain_ |
Ben Finney

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

Re: turtle ??

[Chris Angelico]

On Thu, Mar 10, 2016 at 5:14 PM, Marko Rauhamaa  wrote:
> Chris Angelico :
>
>> A Turkish keyboard should have dotless and dotted, uppercase and
>> lowercase, all easily typed.
>
> BTW, typing any useful Unicode character is a major unsolved problem. I
> have created this text file that contains a lot of unicode characters
> with their code points. Every once in a while I have to open the file
> and copy and paste a character to, say, a Usenet posting. Cumbersome but
> necessary.

Part of the reason it's unsolved is that there are many different ways
you might want to identify the character. Are you looking for a glyph
by name? Grab the unicodedata module (or the \N escape) and print
something out. (Works only if you know the exact name. A fuzzy match
tool would be handy, and would be reasonably easy to build on top of
unicodedata. Someone's probably done that already, but if not, it
wouldn't be a particularly long script.) Are you trying to type text
in a different script? Transliteration from/to Latin letters is
probably the best way - either as an input method (I can right-click
an entry field and select Cyrillic, and then "stop" comes out as
"стоп" - hey look, it translated it into Russian as well!), or as a
dedicated transliteration script. Trying to type Latin letters with
diacriticals? Dead key support is most likely to be the simplest -
type the diacritical, then the base letter, and it enters the combined
form. Or maybe set your keyboard so that Alt-` emits U+0300 COMBINING
GRAVE ACCENT, and then type the base letter followed by Alt-` to add
an accent. Not 100% sure what you want? Have a text file with all the
characters you can't type and often want to use. Cumbersome, maybe,
but not as bad as some other options. :)

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

Re: Pyhon 2.x or 3.x, which is faster?

[Mark Lawrence]

On 10/03/2016 00:58, BartC wrote:

On 09/03/2016 23:35, Mark Lawrence wrote:

On 09/03/2016 23:14, BartC wrote:



(The byte-code compiler for the current version is written in itself. It
can compile itself (some 25Kloc) in about 1 second (that's running
interpreted, dynamic byte-code on a not-very-fast PC).


Please answer my question, will it be tested against real world
benchmarks or microbenchmarks?  The above paragraph, and several
following paragraphs, are completely irrelevant.


You think a bloody great compiler is a microbenchmark?!


I have no interest in the speed of the compiler, I am interested in the 
run time speed of the applications that it produces which is what has 
been discussed thus far.





A compiler is another good 'pure language' task because, apart from
input and output at each end, all the computation is self-contained.)


I've no idea what this is meant to mean.


It means the task doesn't do any function calls to external libraries.


Meaning that in this dreadful place called the real world it's less than 
useless in many cases.  Why do you think there are the better part of 
50,000 entries on pypi alone, some pure Python, some C extensions, 
presumably some a combinaton of both?




If you're benchmarking, that's usually what you want.


I'm not much interested in Unicode at the minute. I'll pass.



Your final comment sums up perfectly your knowledge of computing in
2016.


You're utterly determined to belittle everything I do aren't you!


Yes I am, as you appear to know squat.



But, yeah, I was writing international applications decades ago. I'm not
working for anyone now and don't need to bother.


So your new language doesn't bother with unicode then?



 From what I've seen, a lot of software can't get it right anyway.



Are you referring to PEP393 having taken notice of the RUE?

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Text input with keyboard, via input methods (was: turtle ??)

[Ben Finney]

Marko Rauhamaa  writes:

> BTW, typing any useful Unicode character is a major unsolved problem.

You typed a good number of Unicode characters in that sentence alone.
ASCII is a simple subset of Unicode.

I suppose you meant to refer to typing some character not mapped to a
single keystroke on a US-English keyboard kayout.

You're right, that is a major problem.

As for how solved it is, that depends on what you're hoping for as a
solution.

The conventional solution, which I find to be quite useful for typing
characters from a great many different writing systems, is an
 customised to
particular writing systems.

My primary input method is one which lets me type typical English text
and also easily input a broad range of useful characters with a few
mnenonic two- or three-key sequences.

> I have created this text file that contains a lot of unicode
> characters with their code points. Every once in a while I have to
> open the file and copy and paste a character to, say, a Usenet
> posting. Cumbersome but necessary.

Hopefully your operating system has a good input method system, with
many input methods available to choose from. May you find a decent
default there.

-- 
 \  “It is … incumbent upon us to recognize that it is |
  `\inappropriate for religion to play any role in issues of state |
_o__)[of] a modern democracy.” —Lawrence M. Krauss, 2012-05-28 |
Ben Finney

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

Re: turtle ??

[Jussi Piitulainen]

Marko Rauhamaa writes:

> Chris Angelico :
>
>> A Turkish keyboard should have dotless and dotted, uppercase and
>> lowercase, all easily typed.
>
> BTW, typing any useful Unicode character is a major unsolved
> problem. I have created this text file that contains a lot of unicode
> characters with their code points. Every once in a while I have to
> open the file and copy and paste a character to, say, a Usenet
> posting. Cumbersome but necessary.

C-u M-x python3 -c 'print("\N{TURTLE}", end = "")' RET :)



Though I only see this character as an over-wide box containing the
numeric code 01F422.

Usually I go to the web and search for the character code. Python
unicodedata module does not seem to help if one doesn't know or guess
the exact name, but if one does, unicodedata.lookup("TURTLE") works.

Aha! http://unicode-search.net/unicode-namesearch.pl?term=TURTLE

python3 -c 'print("\N{KANGXI RADICAL TURTLE}")'

⿔

That one shows as a glyph for me, both in Emacs in a terminal and in
Firefox.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: turtle ??

[Marko Rauhamaa]

Chris Angelico :

> A Turkish keyboard should have dotless and dotted, uppercase and
> lowercase, all easily typed.

BTW, typing any useful Unicode character is a major unsolved problem. I
have created this text file that contains a lot of unicode characters
with their code points. Every once in a while I have to open the file
and copy and paste a character to, say, a Usenet posting. Cumbersome but
necessary.


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

Re: A mistake which almost went me mad

[Rustom Mody]

On Wednesday, March 9, 2016 at 10:04:35 PM UTC+5:30, Rick Johnson wrote:
> On Thursday, March 3, 2016 at 4:22:07 AM UTC-6, ast wrote:
> > Hello
> > 
> > This has to be told
> > 
> > I created a file pickle.py in order to test some files
> > read/write with objects and put it in a directory
> > which is on my python path. 
> > 
> > Then the nightmare began
> > 
> > - Idle no longer works, window no longer opens 
> > when double clicked, no errors messsages
> > 
> > - python -m pip list doesnt work, crash with an 
> > error message related to pickle
> > 
> > I uninstalled python34 and reinstalled it, same problem
> > I uninstalled python34 and instaled 3.5, same problem
> > 
> > ...
> > 
> > I finally understood that pickle.py is the name of the file
> > containing the official pickle module.
> > 
> > This module is probably used by various python programs,
> > IDLE, pip ...
> > 
> > Instead of reading official pickle, python read my file ...
> 
> This is a design flaw of the python language. If all standard library modules 
> would have been protected from the global namespace by a single symbol -- say 
> "stdlib" or "py" or whatever -- we would only need to avoid *ONE* symbol, 
> instead of hundreds of them!!! Third party modules should have their own 
> namespace as well. 
> 
>  from stdlib import re
>  from stdlib.re import search
>  from extlib import PIL
>  from extlib.PIL import Image, ImageTk
> 
> Since those responsible for this flaw are unable, or unwilling, to fix it, 
> the only solution for *YOU* is to (1) memorize every module name that exists 
> in the python standard library, and also those that exist in your 
> "site-packages" directory, or (2) hide all your personal modules behind a 
> single symbol by utilizing a package.
>  
>  +mylib
>__init__.py
>pickle.py
> 
> import mylib.pickle as mypickle
> mypickle.do_something()

As usual Rick I find myself agreeing with your direction [also it seems
Random832's direction] though not with the ranty tone.

Ive been collecting factoids about how programming pedagogy and professional
programming practice cannot be conflated under one roof

[See 
http://blog.languager.org/2015/06/functional-programming-moving-target.html ]

One argument against that is -- in some guise or other -- to use namespaces.
eg If you dont need a language-feature dont use it
  If you dont need a library dont use it

These arguments neglect that the namespacing -- semantics, intricacies, 
headaches, etc -- ITSELF may be significantly noob-unfriendly.

For cars one needs: 
- the hood securely fastened when teaching driving
- easily openable when teaching automobile engineering
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue26523] multiprocessing ThreadPool is untested

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

LGTM.

Is it worth to change multiprocessing.Pool in _TestPoolWorkerErrors and 
_TestPoolWorkerLifetime? Currently they work only for processes, but may be 
they can be generalized.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue26509] spurious ConnectionAbortedError logged on Windows

[Sebastien Bourdeauducq]

Sebastien Bourdeauducq added the comment:

Your patch seems to miss the ``_fatal_error`` method in ``proactor_events.py`` 
(which is actually where the bug happens in my application - it's using 
``ProactorEventLoop``).

--

___
Python tracker 

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

Re: turtle ??

[Chris Angelico]

On Thu, Mar 10, 2016 at 1:45 PM, Steven D'Aprano  wrote:
> On Thu, 10 Mar 2016 05:14 am, MRAB wrote:
>
>> FYI, the uppercase of "ı" is "I" and the lowercase of "İ" is "i".
>
> Very true. Does that tell us anything about the placement and ease of
> getting I on a Turkish keyboard?
>
> I'm just giving the OP the benefit of the doubt. Maybe they have a good
> reason for typing l instead of I. Probably not though.

A Turkish keyboard should have dotless and dotted, uppercase and
lowercase, all easily typed. Here's one example layout (I've no idea
how prevalent this is):

http://ascii-table.com/img/keyboard-179.png

But depending on the exact layout used, it might be very easy to typo
I as l, and it may well not be noticed. My guess is that there's no
good reason to mistype, but plenty of good reasons for mistyping to
happen. :)

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

Re: Pyhon 2.x or 3.x, which is faster?

[Chris Angelico]

On Thu, Mar 10, 2016 at 1:38 PM, Jon Ribbens
 wrote:
> On 2016-03-10, Chris Angelico  wrote:
>> On Thu, Mar 10, 2016 at 10:48 AM, Jon Ribbens
>> wrote:
>>> On 2016-03-09, Chris Angelico  wrote:
 Then *get interested*. Unicode is the only way that you'll ever not be
 parochially bound to a subset of English - or, worse, bound to an
 arbitrary eight-bit codepage that you don't even control the choice
 of, such that your program behaves differently on different systems.
 FIX YOUR LANGUAGE and support non-English text.
>>>
>>> You can't even support English text properly without Unicode.
>>> Plenty of English words use non-ASCII characters:
>>> café, crêpe, façade, naïve, dæmon, etc.
>>
>> Like I said, a subset of English.
>
> I profusely apologise for so rudely agreeing with you.

I snapped off a very quick response as I was about to meet with a
student, but let me assure you that I was not offended in any way by
your post. You basically gave examples of exactly the problem that I
alluded to with the words "a subset of", and it's an important enough
consideration that it's well worth having the examples there.

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

Re: turtle ??

[Steven D'Aprano]

On Thu, 10 Mar 2016 05:14 am, MRAB wrote:

> FYI, the uppercase of "ı" is "I" and the lowercase of "İ" is "i".

Very true. Does that tell us anything about the placement and ease of
getting I on a Turkish keyboard? 

I'm just giving the OP the benefit of the doubt. Maybe they have a good
reason for typing l instead of I. Probably not though.


-- 
Steven

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

Re: Pyhon 2.x or 3.x, which is faster?

[Steven D'Aprano]

On Thu, 10 Mar 2016 12:30 pm, BartC wrote:

> But the attitude in this group has been very different; Python is
> slow, but so what? Just a general shrug.

I think that sometimes people here get a bit defensive because they've
experienced too many people making snap dismissals of Python due to some
completely artificial benchmark that doesn't relate to the work that their
actually doing. These are the people who would rather spend two weeks
writing a buggy C program to do a one-off processing task that takes 10
minutes to run that we could do correctly in half a day in Python because
their code is "100 times faster".

You might think I'm exaggerating, but I've seen people do that.

Anyway, the Python community as a whole is *very* aware that Python is not
the speediest language in the world (although it is faster than Ruby,
faster than at least some Javascript implementations, and neither of those
two are suffering in popularity due to slowness). Speed is not the number 1
priority, and possibly not even the number 2 priority, but it is a priority
somewhere in the top 10. Hence there is a whole range of
performance-related factors to be considered:


- speed.python.org allows the core developers (and anyone else) to monitor
Python's performance;

- PyPy is a self-hosted[1] powerful Just-In-Time compiler aimed especially
at long-running code in loops;

- the author of Nuitka is re-writing Python in C++ with the eventual aim of
making it a highly-optimized Ahead-Of-Time compiler;

- one of the core devs, Victor Stinner, is working on FAT Python, an
optimizing implementation;

- other projects include Pyston, Pyjion, HotPy, Cython, Numba, Parakeet.


Some discussion here:

https://www.ibm.com/developerworks/community/blogs/jfp/entry/A_Comparison_Of_C_Julia_Python_Numba_Cython_Scipy_and_BLAS_on_LU_Factorization?lang=en


So don't think that the community as a whole is dismissive of speed issues.
But they're more interested in speeding up Python where it matters.





[1] Well, sort of. PyPy is actually written in RPython, a restricted subset
of Python.


-- 
Steven

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

Re: Pyhon 2.x or 3.x, which is faster?

[Jon Ribbens]

On 2016-03-10, Chris Angelico  wrote:
> On Thu, Mar 10, 2016 at 10:48 AM, Jon Ribbens
> wrote:
>> On 2016-03-09, Chris Angelico  wrote:
>>> Then *get interested*. Unicode is the only way that you'll ever not be
>>> parochially bound to a subset of English - or, worse, bound to an
>>> arbitrary eight-bit codepage that you don't even control the choice
>>> of, such that your program behaves differently on different systems.
>>> FIX YOUR LANGUAGE and support non-English text.
>>
>> You can't even support English text properly without Unicode.
>> Plenty of English words use non-ASCII characters:
>> café, crêpe, façade, naïve, dæmon, etc.
>
> Like I said, a subset of English.

I profusely apologise for so rudely agreeing with you.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pyhon 2.x or 3.x, which is faster?

[Ben Finney]

BartC  writes:

> But, someone had to write that Image.PNG.encode() function at some
> time. What language did they use? If it wasn't Python, then why not?

Because some operations actually need to be very fast, even at the
expense of difficult-to-maintain code in a difficult-to-use language.

> Why is it OK to let some poor sod slave away in C++ or whatever (a
> ghastly language), while others then reap the benefits writing in an
> easy 'soft' language?

Because that's the whole point of writing a small re-usable library and
maintaining it: countless gobs of badly-written imitations thereby never
need to be written.

> I've been interested for a while in broadening the scope of scripting
> languages so that less work has to be done in 'hard' ones.

Yes, that's pretty much the answer to the question you asked above.

> But the attitude in this group has been very different; Python /is/
> slow, but so what? Just a general shrug.

I'm sorry you drew that inference. Comprehensive answers – not a
“general shrug” – have in fact been given to you.

The answer boils down to the fact that there are trade-offs to be made.
One that is easy to express is that Python trades preserving valuable
programmer time, at the expense of some non-critical operations being
slightly slower.

And no, of course it's not “Python is slow”. Such a broad statement is
erxactly what gets mocking scorn in response: you need to be *much* more
specific about what is slow, under what conditions. Python is plenty
fast enough at most of the things it is used for.

> So long as /someone else/ uses the hard language to created the needed
> libraries, the speed of pure Python is irrelevant. New version of
> Python is now half the speed? Another shrug!

Citation needed. I don't know of any released version of Python that was
ever “twice as slow” – no qualifiers – than the previous release.

Make such sweeping, hand-waving statements that are trivially
demonstrated false, and yes your statements will be dismissed. With
sneers by some, and with a shrug by most.

-- 
 \   “It's easy to play any musical instrument: all you have to do |
  `\   is touch the right key at the right time and the instrument |
_o__)will play itself.” —Johann Sebastian Bach |
Ben Finney

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

Re: Pyhon 2.x or 3.x, which is faster?

[Steven D'Aprano]

On Thu, 10 Mar 2016 10:35 am, Mark Lawrence wrote:

> On 09/03/2016 23:14, BartC wrote:

>> (The byte-code compiler for the current version is written in itself. It
>> can compile itself (some 25Kloc) in about 1 second (that's running
>> interpreted, dynamic byte-code on a not-very-fast PC).
> 
> Please answer my question, will it be tested against real world
> benchmarks or microbenchmarks?  The above paragraph, and several
> following paragraphs, are completely irrelevant.

Mark, Bart's answer is a very good answer. He has written a self-hosting
interpreter and compiler. That is a good (although not perfect) "real world
benchmark".

I get it that you're keen to jump into the fray and defend the honour of
Python, but Python doesn't need to be defended from Bart. He's just one
guy, he's retired, and he has an interesting little language as a hobby.
What's the threat? Don't go all Ranting Rick on us and think that the
entire computing community is going to abandon Python for Bart's private
and unpublished language.

I've said it before, and I'll say it again: I think that Bart's language
sounds interesting. I'm not sure exactly where it would sit in the
computing ecosystem, but if it works for him, good for him.


>> The interpreter for the byte-code is also written in another language of
>> mine, which statically typed. The compiler for the latter is written in
>> the interpreted language too.
>>
>> I'd quite like to port either of these compilers to Python, to see what
>> PyPy can do with them. (It would also be quite cool to have them in pure
>> Python). But I've find these difficult to optimise, because they have
>> diverse execution patterns, while PyPy likes loops. I'll see.
>>
>> A compiler is another good 'pure language' task because, apart from
>> input and output at each end, all the computation is self-contained.)
> 
> I've no idea what this is meant to mean.

Then you shouldn't criticise Bart for his lack of "knowledge of computing"
just because he lacks of interest in Unicode. As they say, people in glass
houses shouldn't throw stones.

I think Bart is very old-school, and probably a bit behind the times when it
comes to modern compiler and interpreter technologies. But that doesn't
matter: the old timers knew a thing or two, and in some ways the old days
were better:

http://prog21.dadgum.com/116.html


I fear that Bart still holds quite a few misapprehensions about Python. But
he seems happy to discuss the language, and (unless he is lying to us and
all his claims about his interpreter are pure Walter Mitty fantasy -- and I
have no reason to think this is true), there's no doubt that he is knows
what he is talking about in the areas of which he is qualified to speak.

Does he know Unicode? No. Does he know compiler design? It seems so, which
is more than can be said by either you or I.



-- 
Steven

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

[issue26523] multiprocessing ThreadPool is untested

[Ned Deily]

Changes by Ned Deily :


--
nosy: +davin

___
Python tracker 

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

Re: Pyhon 2.x or 3.x, which is faster?

[BartC]

On 09/03/2016 23:38, Chris Angelico wrote:

On Thu, Mar 10, 2016 at 10:14 AM, BartC  wrote:



program to be actually written in Python. Sometimes you want to understand
how code works or what it does or simply to learn from it. (Or sometimes, to
rip bits off.) Then it's frustrating when you come up against a dead-end so
quickly. Because the real meat isn't in Python at all.


What *is* the real meat of a program? Every action is defined in terms
of smaller actions - a Python program is built out of Python
primitives and function calls, a C program is built out of C
primitives and function calls, an 80x86 machine code program is built
out of 80x86 CPU instructions and calls to other code. Does my MUD
server need to have its own memory allocation code? No. Does it need
an algorithm for adding two integers together? Certainly not! And nor
does it need PNG encoding and decoding algorithms; I simply call on
Image.PNG.encode() and Image.PNG.decode() to do the work, passing
images around in my code as first-class objects. Does it detract from
my code? Not in the least. My code treats "load an image from a PNG
file" as a fundamental operation, and gets on with doing its stuff.


Yes we understand how libraries can be useful.

But, someone had to write that Image.PNG.encode() function at some time. 
What language did they use? If it wasn't Python, then why not?


Why is it OK to let some poor sod slave away in C++ or whatever (a 
ghastly language), while others then reap the benefits writing in an 
easy 'soft' language?


I've been interested for a while in broadening the scope of scripting 
languages so that less work has to be done in 'hard' ones. (Although I 
admit that taking over imaging functions is probably not going to be 
viable, except perhaps for rather small images.)


It seems other have the same idea with the advent of fast JIT systems.

But the attitude in this group has been very different; Python /is/ 
slow, but so what? Just a general shrug. So long as /someone else/ uses 
the hard language to created the needed libraries, the speed of pure 
Python is irrelevant. New version of Python is now half the speed? 
Another shrug!



Reinventing the wheel does NOT intrinsically make your code better.


But you might end up with a small, manageable wheel that does just what 
you want instead of the same 100' monster than everything else is using!


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

Re: Pyhon 2.x or 3.x, which is faster?

[Chris Angelico]

On Thu, Mar 10, 2016 at 11:58 AM, BartC  wrote:
>>> I'm not much interested in Unicode at the minute. I'll pass.
>
>
>> Your final comment sums up perfectly your knowledge of computing in
>> 2016.
>
>
> You're utterly determined to belittle everything I do aren't you!
>
> But, yeah, I was writing international applications decades ago. I'm not
> working for anyone now and don't need to bother.
>
> From what I've seen, a lot of software can't get it right anyway.

That would be because a lot of software is written by people who don't
understand Unicode. "But other people get it wrong too!" wasn't a
valid excuse when I was in grade school, and it still isn't in
real-world work. [1] If you are writing code in 2016 that assumes that
a byte is the same thing as a character, and speak as if this is
alright, then yes, we WILL belittle you for it. It's on par with
thinking that an integer is a 16-bit signed two's complement number.
Sure, back in the 1990s, you could probably get away with that (and
you'll find a lot of games that flip at 32,767 or 65,535 - or, in one
that I remember, at 3,276,700!), but nobody today would let you
pretend that those are identical. Neither is a list identical to a
coherent block of memory (the way a C array often is implemented) -
and neither is a text string identical to a stream of bytes. Even if
you're restricting your text to the ASCII set, there is still an
encoding involved; a typical C string's encoding is "one character per
byte, followed by 0x00", whereas a Pascal string's encoding might be
"one character per byte, preceded by the character count, represented
in a single byte". Every encoding has consequences, every encoding has
costs. You can't get away from this. You can't pretend that you don't
have an encoding.

ChrisA

[1] Except when you're specifically writing compatibility code, where
getting it identically wrong means your program successfully
interoperates with someone else's buggy code. But if you're doing
that, I pity you. That is not a fun job to have.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pickle __getstate__ __setstate__ and restoring n/w - beazley pg 172

[Veek. M]

Ian Kelly wrote:

> On Wed, Mar 9, 2016 at 2:14 AM, Veek. M  wrote:
>> what i wanted to know was, x = Client('192.168.0.1') will create an
>> object 'x' with the IP inside it. When I do:
>> pickle.dump(x)
>> pickle doesn't know where in the object the IP is, so he'll call
>> __getstate__ and expect the return value to be the IP, right?
> 
> pickle doesn't care what the return value is, other than it needs to
> be something picklable. I suggest returning a dict containing the IP
> address, to make it easier to add additional state later if needed.
> 
> That said, I wouldn't pickle a TCP client in the first place. You may
> be able to restore the client state, but you can't easily restore any
> server state, which could easily lead to mismatching network states.
> Also, what do you think should happen if the connection fails while
> unpickling?
> 
Actually that's just what I was asking: when __getstate__ is called, 
it's upto getstate to return the object to be pickled - it could be an 
IP passed in by the user or pretty much anything 'hello world' even.

Anyway, i think the point of that example (from the book) is that he's 
not saving TCP state info. Instead he provides a seamless iface so the 
user won't even realize the connection had failed (meaning he'll reopen 
the link using the pickled IP and pretend the link never went down).

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

Re: Pyhon 2.x or 3.x, which is faster?

[BartC]

On 09/03/2016 23:35, Mark Lawrence wrote:

On 09/03/2016 23:14, BartC wrote:



(The byte-code compiler for the current version is written in itself. It
can compile itself (some 25Kloc) in about 1 second (that's running
interpreted, dynamic byte-code on a not-very-fast PC).


Please answer my question, will it be tested against real world
benchmarks or microbenchmarks?  The above paragraph, and several
following paragraphs, are completely irrelevant.


You think a bloody great compiler is a microbenchmark?!


A compiler is another good 'pure language' task because, apart from
input and output at each end, all the computation is self-contained.)


I've no idea what this is meant to mean.


It means the task doesn't do any function calls to external libraries.

If you're benchmarking, that's usually what you want.


I'm not much interested in Unicode at the minute. I'll pass.



Your final comment sums up perfectly your knowledge of computing in
2016.


You're utterly determined to belittle everything I do aren't you!

But, yeah, I was writing international applications decades ago. I'm not 
working for anyone now and don't need to bother.


From what I've seen, a lot of software can't get it right anyway.

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

Re: Pyhon 2.x or 3.x, which is faster?

[Ben Finney]

Chris Angelico  writes:

> On Thu, Mar 10, 2016 at 10:14 AM, BartC  wrote:
> > I'm not much interested in Unicode at the minute. I'll pass.
>
> Then *get interested*. Unicode is the only way that you'll ever not be
> parochially bound to a subset of English - or, worse, bound to an
> arbitrary eight-bit codepage that you don't even control the choice
> of, such that your program behaves differently on different systems.

Yes. Any program (and therefore, any programmer) that deals with text in
any way today needs to be Unicode-aware.

This is true whether or not you care about diverse languages. It's no
longer the case that ASCII is enough *even if you arbitrarily limit your
program to English text*.

English text uses non-ASCII characters all the time. Proper punctuation
(e.g. quotation, dashes). Proper spacing (e.g. thin space, no-break
space). Currency symbols (e.g. the Yuan, the Euro, the pound). Official
symbols (e.g. copyright, trademark, degree, section).

If your program fails to preserve these and many other non-ASCII
characters, fails to treat them like any other text, your program does
not handle English-language text.

Many names – of people and places and organisations – cannot be spelled
correctly, even in English, without using non-ASCII characters.

Text was never the same as bytes. Programs hobbled along in the 20th
century making that false assumption, and the problems led to the
creation of Unicode.

Your program will read and write bytes in byte streams (such as files).
They will not write text directly. The only sense in which you can say
that you get text from a file is if you know the text encoding of the
bytes.

This is just a brute fact. You can't have text being anywhere near
bytes, without knowing the text encoding. Guessing is not good enough in
the third millennium.

-- 
 \ “[…] we don’t understand what we mean when we say that [God] is |
  `\‘good’, ‘wise’, or ‘intelligent’.” —Karen Armstrong, _The Case |
_o__)   For God_, 2009 |
Ben Finney

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

[issue26322] Missing docs for typing.Set

[Joseph Moran]

Joseph Moran added the comment:

Deleted second ABSTRACTSET and added SET in typing docs

--
nosy: +joegotflow83
Added file: http://bugs.python.org/file42109/26322

___
Python tracker 

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

[issue26396] Create json.JSONType

[Jakub Stasiak]

Changes by Jakub Stasiak :


--
nosy: +jstasiak

___
Python tracker 

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

Re: Pyhon 2.x or 3.x, which is faster?

[Chris Angelico]

On Thu, Mar 10, 2016 at 10:48 AM, Jon Ribbens
 wrote:
> On 2016-03-09, Chris Angelico  wrote:
>> Then *get interested*. Unicode is the only way that you'll ever not be
>> parochially bound to a subset of English - or, worse, bound to an
>> arbitrary eight-bit codepage that you don't even control the choice
>> of, such that your program behaves differently on different systems.
>> FIX YOUR LANGUAGE and support non-English text.
>
> You can't even support English text properly without Unicode.
> Plenty of English words use non-ASCII characters:
> café, crêpe, façade, naïve, dæmon, etc.

Like I said, a subset of English.

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

Re: Pyhon 2.x or 3.x, which is faster?

[Jon Ribbens]

On 2016-03-09, Chris Angelico  wrote:
> Then *get interested*. Unicode is the only way that you'll ever not be
> parochially bound to a subset of English - or, worse, bound to an
> arbitrary eight-bit codepage that you don't even control the choice
> of, such that your program behaves differently on different systems.
> FIX YOUR LANGUAGE and support non-English text.

You can't even support English text properly without Unicode.
Plenty of English words use non-ASCII characters:
café, crêpe, façade, naïve, dæmon, etc.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pyhon 2.x or 3.x, which is faster?

[Chris Angelico]

On Thu, Mar 10, 2016 at 10:14 AM, BartC  wrote:
> On 09/03/2016 21:13, Mark Lawrence wrote:
>>
>> On 09/03/2016 12:02, BartC wrote:
>>>
>>> On 09/03/2016 08:40, Mark Lawrence wrote:
>>>
>>> Here's another: you have a program in Python that you'd quite like to
>>> port to another dynamic language. Transcribing actual Python code is
>>> straightforward. Until you come to an import of a module that you can't
>>> find, because it's not written in Python. Now what? Now, you might
>>> appreciate the advantage of a program in 100% pure Python.
>>>
>>
>> That is not Python's problem, or my problem, that is your problem.
>
>
> Maybe that's not the best example of why someone might prefer a 'Python'
> program to be actually written in Python. Sometimes you want to understand
> how code works or what it does or simply to learn from it. (Or sometimes, to
> rip bits off.) Then it's frustrating when you come up against a dead-end so
> quickly. Because the real meat isn't in Python at all.

What *is* the real meat of a program? Every action is defined in terms
of smaller actions - a Python program is built out of Python
primitives and function calls, a C program is built out of C
primitives and function calls, an 80x86 machine code program is built
out of 80x86 CPU instructions and calls to other code. Does my MUD
server need to have its own memory allocation code? No. Does it need
an algorithm for adding two integers together? Certainly not! And nor
does it need PNG encoding and decoding algorithms; I simply call on
Image.PNG.encode() and Image.PNG.decode() to do the work, passing
images around in my code as first-class objects. Does it detract from
my code? Not in the least. My code treats "load an image from a PNG
file" as a fundamental operation, and gets on with doing its stuff.

Reinventing the wheel does NOT intrinsically make your code better.
Unless there's something you're doing that's fundamentally different
from what's already available (maybe a database client that uses
non-blocking sockets with async/await), it's usually better to use
what someone else has written. I'd much rather use a one-liner that
reads an image from the disk than wade through your pages and pages of
bitshift operations in Python (especially as it's all uncommented -
how can I know if it's even correct, other than by finding a reference
algorithm written in C?).

>> Python 2.8 or RickedPython?  Will the unicode handling be better than
>> that of the dread Python 3.3+, PEP393 Flexible String Representation > as
>> repeatedly pointed out by the RUE?
>
> I'm not much interested in Unicode at the minute. I'll pass.

Then *get interested*. Unicode is the only way that you'll ever not be
parochially bound to a subset of English - or, worse, bound to an
arbitrary eight-bit codepage that you don't even control the choice
of, such that your program behaves differently on different systems.
FIX YOUR LANGUAGE and support non-English text. Integers, floating
point numbers, lists, and images all need encodings; so does text.
It's an abstract data type, just as the others are.

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

Re: Pyhon 2.x or 3.x, which is faster?

[Mark Lawrence]

On 09/03/2016 23:14, BartC wrote:

On 09/03/2016 21:13, Mark Lawrence wrote:

On 09/03/2016 12:02, BartC wrote:

On 09/03/2016 08:40, Mark Lawrence wrote:

Here's another: you have a program in Python that you'd quite like to
port to another dynamic language. Transcribing actual Python code is
straightforward. Until you come to an import of a module that you can't
find, because it's not written in Python. Now what? Now, you might
appreciate the advantage of a program in 100% pure Python.



That is not Python's problem, or my problem, that is your problem.


Maybe that's not the best example of why someone might prefer a 'Python'
program to be actually written in Python. Sometimes you want to
understand how code works or what it does or simply to learn from it.
(Or sometimes, to rip bits off.) Then it's frustrating when you come up
against a dead-end so quickly. Because the real meat isn't in Python at
all.

Actually, you're doing a good job of arguing for not doing using Python
for real coding! Apart from just launching tasks.


Not that it matters, when you release BartC or whatever you call your
language it'll take over the world, so I'm looking forward to dropping
Python.  What is the release date?


(A first version might have been around 1986. I can't remember exactly.
Perhaps you think this is vapourware? It's not a commercial product at
the minute, just a hobby. Originally it was a scripting language for a
commercial app of mine.)


Could it be the same as that for
 Performance wise will it be tested
against real world benchmarks or microbechmarks?


(The byte-code compiler for the current version is written in itself. It
can compile itself (some 25Kloc) in about 1 second (that's running
interpreted, dynamic byte-code on a not-very-fast PC).


Please answer my question, will it be tested against real world 
benchmarks or microbenchmarks?  The above paragraph, and several 
following paragraphs, are completely irrelevant.




The interpreter for the byte-code is also written in another language of
mine, which statically typed. The compiler for the latter is written in
the interpreted language too.

I'd quite like to port either of these compilers to Python, to see what
PyPy can do with them. (It would also be quite cool to have them in pure
Python). But I've find these difficult to optimise, because they have
diverse execution patterns, while PyPy likes loops. I'll see.

A compiler is another good 'pure language' task because, apart from
input and output at each end, all the computation is self-contained.)


I've no idea what this is meant to mean.



 > Python 2.8 or RickedPython?  Will the unicode handling be better than
 > that of the dread Python 3.3+, PEP393 Flexible String Representation
 > as repeatedly pointed out by the RUE?

I'm not much interested in Unicode at the minute. I'll pass.



Your final comment sums up perfectly your knowledge of computing in 
2016.  I find it fitting that something so funny is put forward on the 
Python mailing list/news group/whatever, given the derivation of the 
name Python.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: Pyhon 2.x or 3.x, which is faster?

[BartC]

On 09/03/2016 21:13, Mark Lawrence wrote:

On 09/03/2016 12:02, BartC wrote:

On 09/03/2016 08:40, Mark Lawrence wrote:

Here's another: you have a program in Python that you'd quite like to
port to another dynamic language. Transcribing actual Python code is
straightforward. Until you come to an import of a module that you can't
find, because it's not written in Python. Now what? Now, you might
appreciate the advantage of a program in 100% pure Python.



That is not Python's problem, or my problem, that is your problem.


Maybe that's not the best example of why someone might prefer a 'Python' 
program to be actually written in Python. Sometimes you want to 
understand how code works or what it does or simply to learn from it. 
(Or sometimes, to rip bits off.) Then it's frustrating when you come up 
against a dead-end so quickly. Because the real meat isn't in Python at all.


Actually, you're doing a good job of arguing for not doing using Python 
for real coding! Apart from just launching tasks.



Not that it matters, when you release BartC or whatever you call your
language it'll take over the world, so I'm looking forward to dropping
Python.  What is the release date?


(A first version might have been around 1986. I can't remember exactly. 
Perhaps you think this is vapourware? It's not a commercial product at 
the minute, just a hobby. Originally it was a scripting language for a 
commercial app of mine.)



Could it be the same as that for
 Performance wise will it be tested
against real world benchmarks or microbechmarks?


(The byte-code compiler for the current version is written in itself. It 
can compile itself (some 25Kloc) in about 1 second (that's running 
interpreted, dynamic byte-code on a not-very-fast PC).


The interpreter for the byte-code is also written in another language of 
mine, which statically typed. The compiler for the latter is written in 
the interpreted language too.


I'd quite like to port either of these compilers to Python, to see what 
PyPy can do with them. (It would also be quite cool to have them in pure 
Python). But I've find these difficult to optimise, because they have 
diverse execution patterns, while PyPy likes loops. I'll see.


A compiler is another good 'pure language' task because, apart from 
input and output at each end, all the computation is self-contained.)


> Python 2.8 or RickedPython?  Will the unicode handling be better than
> that of the dread Python 3.3+, PEP393 Flexible String Representation 
> as repeatedly pointed out by the RUE?


I'm not much interested in Unicode at the minute. I'll pass.

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

[issue26506] hex() documentation: mention "%x" % int

[STINNER Victor]

STINNER Victor added the comment:

> Ah, but it's not that format() is slower in 3.5, but that %-formatting got 
> faster.

Hum, python3 looks faster on this dummy microbenchmark yeah. Who said that 
Python 3 is slower? :-)

$ python2 -m timeit -s 'import random; nums = [random.randint(0, 255) for n in 
range(10**5)]' '["%x" % x for x in nums]'
10 loops, best of 3: 43.7 msec per loop

$ python3 -m timeit -s 'import random; nums = [random.randint(0, 255) for n in 
range(10**5)]' '["%x" % x for x in nums]'
10 loops, best of 3: 19.2 msec per loop

I spent a lot time to micro-optimize str%args, str.format(args), and operations 
on str in general in Python 3. I wrote a first article to explain my work on 
optimization:
https://haypo.github.io/pybyteswriter.html

I have a draft article explaning other kinds of optimizations related to the 
PEP 393.

> It looks as if it got optimized and I was wondering whether the same 
> optimization could be applied to format().

str.format(args) was also optimized, but it's still faster than str%args.

On Python 3, "%x" % 0x1234abc takes 17 nanoseconds according to timeit. It's 
super fast! Any extra work can have a non negligible overhead. For example, 
it's known that operators are faster than functions in Python. One reason is 
that a calling requires to lookup the function in namespaces (local, global or 
builtin namespaces). It can be even worse (slower) to lookup a method 
(especially with custom __getattr__ method).

--

Hum, I don't recall why you started to talk about performance :-D

Why not documenting "%x" % value *and* format(value, 'x')?

I prefer "%x" % value. I never use format(value, ...) but sometimes I use 
"{0:x}".format(value).

f'{x:value}' looks too magical for me.

--

___
Python tracker 

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

[issue20211] setup.py: do not add invalid header locations

[Mark Lawrence]

Changes by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

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

[issue26506] hex() documentation: mention "%x" % int

[Wolfgang Maier]

Wolfgang Maier added the comment:

Ah, but it's not that format() is slower in 3.5, but that %-formatting got 
faster.
It looks as if it got optimized and I was wondering whether the same 
optimization could be applied to format().

--

___
Python tracker 

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

[issue26506] hex() documentation: mention "%x" % int

[Eric V. Smith]

Eric V. Smith added the comment:

Without lots of analysis (and disassembly), I can't speak to how valid your 
tests are, but they don't seem unreasonable.

format() will always be slower, because it's more general (primarily in that it 
can be extended to new types). Plus, it involves at least a name lookup that 
%-formatting can skip. The usual ways to optimize this lookup holds here, too, 
if speed is really that critical (which I'm skeptical of).

For example, say you had a custom type which implemented __format__ to 
understand the "X" format code. Using format(), this type could format itself 
as hex. %-formatting can't do that.

In any event, I don't think we want to promulgate the fastest way to do a hex 
conversion, just the clearest.

I can't say why format() in 3.5 is slower. There are many changes and tracking 
it down would be quite time consuming.

--

___
Python tracker 

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

Re: Pickle __getstate__ __setstate__ and restoring n/w - beazley pg 172

[Ian Kelly]

On Wed, Mar 9, 2016 at 2:14 AM, Veek. M  wrote:
> what i wanted to know was, x = Client('192.168.0.1') will create an
> object 'x' with the IP inside it. When I do:
> pickle.dump(x)
> pickle doesn't know where in the object the IP is, so he'll call
> __getstate__ and expect the return value to be the IP, right?

pickle doesn't care what the return value is, other than it needs to
be something picklable. I suggest returning a dict containing the IP
address, to make it easier to add additional state later if needed.

That said, I wouldn't pickle a TCP client in the first place. You may
be able to restore the client state, but you can't easily restore any
server state, which could easily lead to mismatching network states.
Also, what do you think should happen if the connection fails while
unpickling?

> Similarly, whilst unpickling, __setstate__ will be called in a manner
> similar to this:
> x.__setstate__(self, unpickledIP)
>
> __setstate__ can then populate 'x' by doing
> self.x = str(unpickledIP)
>
> the type info is not lost during pickling is it, therefore 'str' is not
> required is it?

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

[issue26522] pickle.whichmodule(object.__new__, None) = 'email.MIMEAudio'

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


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

___
Python tracker 

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

Re: Pyhon 2.x or 3.x, which is faster?

[Mark Lawrence]

On 09/03/2016 12:02, BartC wrote:

On 09/03/2016 08:40, Mark Lawrence wrote:

Here's another: you have a program in Python that you'd quite like to
port to another dynamic language. Transcribing actual Python code is
straightforward. Until you come to an import of a module that you can't
find, because it's not written in Python. Now what? Now, you might
appreciate the advantage of a program in 100% pure Python.



That is not Python's problem, or my problem, that is your problem.

Not that it matters, when you release BartC or whatever you call your 
language it'll take over the world, so I'm looking forward to dropping 
Python.  What is the release date?  Could it be the same as that for 
Python 2.8 or RickedPython?  Will the unicode handling be better than 
that of the dread Python 3.3+, PEP393 Flexible String Representation as 
repeatedly pointed out by the RUE?  Performance wise will it be tested 
against real world benchmarks or microbechmarks?  Better still, will it 
be bug free, such that I don't have to waste my time on the equivalent 
of bugs.python.org raising problems, which should have been foreseen by 
your one man crew?


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

[issue26506] hex() documentation: mention "%x" % int

[Wolfgang Maier]

Wolfgang Maier added the comment:

Your two suggestions prompted me to do a speed comparison between them and the 
result surprised me.

I tried:

import random
nums = [random.randint(0, 255) for n in range(1000)]

then timed the simple:

for n in nums:
hx = '%X' % n  # or hx = format(n, 'X')

I also tested a number of more complex formats like:
hx = '%{:02X}'.format(n) vs hx = '%%%02X' % n

In all cases, the old vs new formatting styles are rather similar in speed in 
my system Python 2.7.6 (with maybe a slight advantage for the format-based 
formatting).
In Python 3.5.0, however, old-style %-formatting is much speedier than under 
Python 2, while new-style formatting doesn't appear to have changed much, with 
the result that %-formatting is now between 30-50% faster than format-based 
formatting.

So I guess my questions are:

- are my timings wrong?

and if not:

- how got %-formatting improved (generally? or for %X specifically?)
- can this speed up be transferred to format-based formatting somehow?

--
nosy: +wolma

___
Python tracker 

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

[issue26524] document what config directory is used for

[John Beck]

New submission from John Beck:

Solaris ships Python versions 2.7, 3.4 and 3.5 at present.  For 2.7,
we ship both 32-bit and 64-bit versions; for 3.4 and 3.5 we only ship
64-bit versions.  For 2.7, we ship /usr/lib/python2.7/config/ with the
usual suspects (Makefile, Setup.config, config.c, install-sh, python.o,
Setup, Setup.local, config.c.in, makesetup) thereunder for the 32-bit
version but for the 64-bit version, we don't ship the equivalent
directory at all.  For 3.4 and 3.5, we ship
/usr/lib/python3.[45]/config-3.[45]m/ with its usual suspects.  We had
a bug filed about the discrepancy in shipping the 32-bit but not the
64-bit version of that directory for 2.7.  An investigation suggested
the directory is not used for 2.7, nor did it seem used (per docs we
could find) for 3.x.  But testing revealed it is used for 3.x, as our
builds failed, e.g.:

error: invalid Python installation: unable to open
/usr/lib/python3.4/config-3.4m/Makefile (No such file or directory)

when we removed the config-3.[45]m directories.  OK, fine, it was an
experiment, so we'll keep the directories.  But it was not clear to
us from the docs we could find, such as:
https://docs.python.org/3.6/extending/extending.html
exactly how the config directory is used.  This is a documentation
enhancement request to clarify how the config directory is used.

--
assignee: docs@python
components: Documentation
messages: 261477
nosy: docs@python, jbeck
priority: normal
severity: normal
status: open
title: document what config directory is used for
versions: Python 3.6

___
Python tracker 

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

[issue26523] multiprocessing ThreadPool is untested

[Antoine Pitrou]

Antoine Pitrou added the comment:

Turns out a couple of tests were calling multiprocessing.Pool directly, 
updating patch.

--
Added file: http://bugs.python.org/file42108/test_threadpool2.patch

___
Python tracker 

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

[issue26520] asyncio.new_event_loop() hangs

[Guido van Rossum]

Guido van Rossum added the comment:

Closing the loop is not taken care of by GC, so I would start there.
AFAIK that's covered by the docs, but if you think the docs could be
clearer please do submit a separate issue with a documentation update
(you can easily submit a patch for that!).

It would be more useful as a bug report if you boiled it down to a
small stand-alone program that exhibits the bug, rather than saying
"in production, after many hours, I get a traceback" (the code you
posted by itself is not enough to repro the issue, since you never
show what the coroutine does).

--

___
Python tracker 

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

[issue26523] multiprocessing ThreadPool is untested

[Antoine Pitrou]

New submission from Antoine Pitrou:

There is a mistake in _test_multiprocessing.py which means that ThreadPool is 
untested, the regular Pool is tested instead by the ThreadsMixin.  Patch 
attached.

--
components: Library (Lib), Tests
files: test_threadpool.patch
keywords: patch
messages: 261474
nosy: jnoller, neologix, pitrou, sbt
priority: normal
severity: normal
stage: patch review
status: open
title: multiprocessing ThreadPool is untested
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42107/test_threadpool.patch

___
Python tracker 

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

[issue26520] asyncio.new_event_loop() hangs

[Erwin Mayer]

Erwin Mayer added the comment:

I understand that asyncio is not .NET and did my best to implement "by the 
book" according to the asyncio documentation I read extensively.
My await_async function has in fact nothing in common with what I would do in 
.NET but is hopefully as close as possible to the canonical way to create and 
consume a loop.
The only maybe non standard thing I do is create a lot of short-lived loops, 
but nothing in the documentation indicates this heavy usage can cause 
instability/freezing.

The case I am reporting can therefore be seen as an asyncio stress test and is 
worrisome as if there is indeed a bug, it could occur randomly when creating a 
single loop as well.

So far, I cannot see anything in my implementation that would be fundamentally 
wrong (for example: do we need to always call close() on a loop, or is it taken 
care of by the GC). I can provide remote access to my screen when the issue 
occurs if it helps, and will post a bounty on my StackOverflow question 
tomorrow.

--

___
Python tracker 

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

Re: Improving performance in matrix operations

[Fabien]

On 03/09/2016 09:09 PM, Drimades wrote:

Another thing to consider is that matrices I'm processing are heavily sparse.


Did you look at scipy.sparse.linalg ?

http://docs.scipy.org/doc/scipy/reference/sparse.linalg.html
--
https://mail.python.org/mailman/listinfo/python-list

[issue26521] add `extend_enum` to Enum

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

To me, the essential property of enums in other languages is that there is 
known limited set of possible values. If this set is dynamically extended, this 
is not enum.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

Improving performance in matrix operations

[Drimades]

I'm doing some tests with operations on numpy matrices in Python. As an 
example, it takes about 3000 seconds to compute eigenvalues and eigenvectors 
using scipy.linalg.eig(a) for a matrix 6000x6000. Is it an acceptable time? Any 
suggestions to improve? Does C++ perform better with matrices? Another thing to 
consider is that matrices I'm processing are heavily sparse.
Do they implement any parallelism? While my code is running, one of my cores is 
100% busy, the other one 30% busy.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue26522] pickle.whichmodule(object.__new__, None) = 'email.MIMEAudio'

[Richard Futrell]

Richard Futrell added the comment:

Ah, I get the same result as you in a clean interpreter session. Looks like 
it's not Python's fault.

The bug seems to arise from an interaction with cloudpickle 0.2.1 (and only in 
IPython), which puts the bad value into a cache somewhere in the pickle module.

So I'll take this issue to cloudpickle. 



In [1]: import cloudpickle

In [2]: cloudpickle.dumps(object.__new__)
Out[2]: '\x80\x02cemail.MIMEAudio\n__new__\nq\x00.'

In [3]: import pickle

In [4]: pickle.whichmodule(object.__new__, None)
Out[4]: 'email.MIMEAudio'

--
resolution:  -> not a bug

___
Python tracker 

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

[issue26499] http.client.IncompleteRead from HTTPResponse read after part reading file

[SilentGhost]

SilentGhost added the comment:

All the highlighted issue are now fixed. The limit on n in read1 wasn't tested.

Your suggestion regarding testing went a bit over my head, Martin. So, just 
trying to make sure we're on the same page. ExtendedReadTest, where I thought 
placing these new tests, is already employing FakeSocket, but I'm not sure how 
one would add a second response and to what. In any case, some of the code in 
that class seems rather specific, so it's not clear if it could or should be 
reused.

--
Added file: http://bugs.python.org/file42106/issue26499_3.diff

___
Python tracker 

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

[issue26522] pickle.whichmodule(object.__new__, None) = 'email.MIMEAudio'

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I get other result:

>>> import pickle
>>> pickle.whichmodule(object.__new__, None)
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/serhiy/py/cpython2.7/Lib/pickle.py", line 823, in whichmodule
if name != '__main__' and getattr(module, funcname, None) is func:
TypeError: getattr(): attribute name must be string

Could you please provide the full example?

--
nosy: +serhiy.storchaka

___
Python tracker 

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

Re: Creating barrel distortion of video

[semeon . risom]

On Tuesday, 8 March 2016 19:46:18 UTC-6, Ben Finney  wrote:
> semeon.ri...@gmail.com writes:
> 
> > This may seem like an odd request for the main python google group
> 
> (Note that this is not a Google group. Google may be presenting this
> forum to you, but it's not exclusive to Google and many of us don't
> participate there.)
> 
> > but I thought this question might have answers coming from different
> > backgrounds that utilize python.
> 
> Your question is fine for this forum. Thanks for investigating Python!
> 
> > I'm trying to find a way of rendering an optical distortion on a video
> > I will be presenting through the use of a head-mounted display. This
> > distortion is necessary to correct the video due to the optics being
> > used. Any advice on a module(s) or examples that already do this?
> 
> I have no experience with such a library. Possible candidates include:
> 
> * moviepy: Video editing with Python
>   
> 
> * pygame: wrapper module for the SDL multimedia library
>   
> 
> -- 
>  \  "Holy hole in a donut, Batman!" --Robin |
>   `\   |
> _o__)  |
> Ben Finney

I'll check both of these out. Thank you
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Creating barrel distortion of video

[semeon . risom]

On Tuesday, 8 March 2016 19:53:10 UTC-6, Chris Angelico  wrote:
> On Wed, Mar 9, 2016 at 12:32 PM,   wrote:
> > This may seem like an odd request for the main python google group, but I 
> > thought this question might have answers coming from different backgrounds 
> > that utilize python.
> >
> > I'm trying to find a way of rendering an optical distortion on a video I 
> > will be presenting through the use of a head-mounted display. This 
> > distortion is necessary to correct the video due to the optics being used. 
> > Any advice on a module(s) or examples that already do this?
> >
> 
> Hi! Seems like a perfectly reasonable request; there are tens of
> thousands of packages listed on the Python Package Index, and this
> mailing list is one of the best places to find advice!
> 
> Are you playing the video in real-time, or is it stored in a file that
> you'll end up playing? If the latter, I would recommend looking into
> FFMpeg (or its fork AVConv), which has an insane number of features,
> and quite likely has what you want. It'll read in a file and write out
> a file.
> 
> If it's real-time, though, I'm not sure what's best to do. Do you know
> exactly what distortion you're trying to perform here?
> 
> ChrisA

It'll be a barrel distortion. I won't need real time processing, and I'll be 
sure to check out both FFMpeg and it's fork. Thank you!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: it doesn't want to open

[sohcahtoa82]

On Wednesday, March 9, 2016 at 10:40:27 AM UTC-8, mashaer elmekki wrote:
> Sent from Windows Mail

Did you try to attach a screenshot or something?  This mailing list is text 
only.  Your attachment will be removed.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: it doesn't want to open

[Rick Johnson]

On Wednesday, March 9, 2016 at 12:48:45 PM UTC-6, Grant Edwards wrote:
> Um, twist it the other way?

I don't think he's trying to open a can Grant, this sounds like a *REAL* 
emergency. My guess is that he is emailing us from the toilet because he needs 
advice on how to free a stuck zipper. Unfortunately for him, i don't have any 
good answers for that one -- he may just have to sacrifice those jeans.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: exit from Tkinter mainloop Python 2.7

[Rick Johnson]

On Friday, March 4, 2016 at 3:50:43 PM UTC-6, kevin...@gmail.com wrote:
> Thanks for your attention to this matter.
> My code now look like this: [...]

All of the help offered in this thread ignores the elephant
in the room. What are you trying to achieve here Kevin? To
me, this looks like some sort of dialog, but if it is a
dialog, the whole design is a miserable failure. And why in
the hell would you call the w.quit() method when the user
presses a "continue" button? Do you realize that the quit
method does not "close the dialog" (if you can call this a
dialog), no, but simply instructs Tkinter to stop processing
events? Once a user clicks your "continue" button, he can no
longer interact with the GUI, and the user is left in a
state of befuddlement.

Those who've attempted to help you have suggested that you
utilize the quit method in your "continue button callback"
so that the widgets will stay alive long enough for you to
fetch the value, but that is horrible advice. Trust me, the
quit method is not something you want to use unless you know
what you're doing. It's should never be used in daily
coding, and only in very specific advanced circumstances.

The destroy method that you utilized initially *IS* the
correct course of action here. You see, your interface is
not a failure because of the destroy method, no, it is a
failure because you failed to (1) fetch the values in the
button callback BEFORE the widgets are destroyed, and (2)
You failed to store those values somewhere that will be
persistent after the function returns. But even if you
followed both of these suggestions, you design is flawed.

If you want to create a proper "dialog interface", the key
is not to use the "quit" method, but to follow these simple
design rules:

  (1) Present the user with a "focused window" that contains
  "form" filled with "input fields" that will facilitate the
  inputting of the required values. Typically, but not
  always, you'll want this window to block program execution
  until the user submits the form (FYI: Dialogs that block
  are commonly referred to as "modal dialogs")
  
  (2) Include at least one button to submit the values. This
  button is typically named "Okay", or "Yes" or "Submit".
  But when the user presses this button, the dialog will
  *NOT* be closed until the values have been validated. If
  the values are found to be inadequate, the dialog will
  inform the user of his mistakes and refocus the input-form
  for editing. A more advanced dialog will utilize fields
  that validate their *OWN* values in "real time". These
  "real time validations" are less likely to confuse a user,
  and they facilitate a more efficient interface since the
  user will be aware of mistakes as they occur.
  
  (3) Include at least one button to cancel the interaction.
  Sometimes, a user will open a dialog accidentally, or for
  some other reason decide that they need a way out. For
  instance: Imagine all the times that you've accidentally
  pressed the X button on a window. If the window closed
  without first asking you "Do you really want to close
  without saving changes", you'd be screwed!

A proper "dialog window" will be constructed of three basic
top-level components:

+--+
|DIALOG_TITLE  |
+--+
|  |
|   DIALOG_BODY|
|  |
+--+
|  DIALOG_BUTTONS  |
+--+

The DIALOG_TITLE is simply a string that will be displayed
in the title bar of the dialog. The DIALOG_BODY is a fluid
area in the middle that can be filled with user-editable
fields, and the DIALOG_BUTTONS is an area at the bottom
where appropriate buttons will be displayed.

A proper dialog object will allow the caller to display the
dialog in either "modal" or "non-modal" forms, and it will
expose hooks that will allow the programmer to customize the
validation and submission of the form data. An even more
advanced version will require the programmer to extend a
"form object" and pass it into the constructor.

Fortunately, the tkSimpleDialog has already wrapped *SOME*
of this functionality up for you. All you need to do is
import the class and override a few "virtual methods" to
achieve your desired goal. The tkSimpleDialod.Dialog class
exposes 3 hooks that you can utilize to modify the behavior

  (1) body: In this method you create your widgets.It
  requires one argument which is a tk.Frame instance that
  the widgets can be made a child of.
  
  (2) validate: in this method you validate your widgets and
  return a Boolean flag. If you don't need any validation
  then don't bother to override it.
  
  (3) apply: In this method you can do something with the
  "dialog.result" *AFTER* the dialog closes. Typically
  though, you will handle this action from outside the
  dialog object. But in certain limited circumstances, it
  can 

[issue26520] asyncio.new_event_loop() hangs

[Guido van Rossum]

Guido van Rossum added the comment:

Asyncio is not .NET. Don't assume that what's "by the book" according
to .NET applies to asyncio.

--

___
Python tracker 

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

[issue26520] asyncio.new_event_loop() hangs

[Erwin Mayer]

Erwin Mayer added the comment:

I simply need to run a coroutine synchronously (which may or may not have a 
loop parameter), so I tried to do it by the book. With .NET it is easy to call 
.Wait() on a Task (but .NET by default uses a threadpool, not a single-threaded 
event loop).

I am intrigued: how is it possible to achieve this at all without creating an 
event loop, and what kind of things are you referring to that could go wrong 
with my implementation?

I am a bit scared as well as if this canonical way to use loops fails for no 
good reason, it may imply other things in asyncio could go wrong. Unless proven 
otherwise (I do not rule out an implementation mistake), there could be a bug 
here, hence this post (StackOverflow is generally of little help when it comes 
to bugs).

--

___
Python tracker 

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

[issue26521] add `extend_enum` to Enum

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

I was thrown off a bit by the description below.  it's not that the OP wants to 
generate an Enum lazily (the functional API lets them do that), it's that the 
OP wants to *extend* an Enum lazily.

Seems like a pretty obscure use case to me.  I'd vote for letting it live in SO 
and not putting it in the stdlib.

--

___
Python tracker 

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

[issue26522] pickle.whichmodule(object.__new__, None) = 'email.MIMEAudio'

[Richard Futrell]

New submission from Richard Futrell:

On Python 2.7.11, pickle.whichmodule(object.__new__, None) = 'email.MIMEAudio'

This is unlikely to be the correct module.

--
components: XML
messages: 261465
nosy: canjobear
priority: normal
severity: normal
status: open
title: pickle.whichmodule(object.__new__, None) = 'email.MIMEAudio'
versions: Python 2.7

___
Python tracker 

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

Re: even faster heaps

[Sven R. Kunze]

On 09.03.2016 19:19, Sven R. Kunze wrote:



ps: there are two error's when i ran tests with test_xheap.


Damn. I see this is Python 2 and Python 3 related. Thanks for bringing 
this to my attention. I am going to fix this soon.


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

[issue26521] add `extend_enum` to Enum

[Ethan Furman]

New submission from Ethan Furman:

In this SO question [1] the OP has a need to generate an Enum lazily.  I 
created an `extend_enum` function to do so.  By the time I was done I realized 
I would not want anyone to have to create that function by hand, nor keep it up 
to date (should we ever change the implementation details).

Should we add this to the stdlib?  Note that this does not change anything 
about subclassing Enum.

[1] http://stackoverflow.com/q/28126314/208880

--
assignee: ethan.furman
messages: 261464
nosy: barry, eli.bendersky, ethan.furman
priority: low
severity: normal
status: open
title: add `extend_enum` to Enum
versions: Python 3.6

___
Python tracker 

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

[issue26512] Vocabulary: Using "integral" in library/stdtypes.html

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

> Can you provide a source ?

How about a dictionary?  For example, Oxford English Dictionary has

"""
integral, adj. and n.

4. Math.

 a. That is, or is denoted by, an integer, or involves only integers; 
consisting of a whole number or undivided quantity; not fractional, or not 
involving a fraction.
"""

http://www.oed.com/view/Entry/97344?redirectedFrom=integral#eid

--

___
Python tracker 

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

Re: it doesn't want to open

[Grant Edwards]

Um, twist it the other way?

-- 
Grant Edwards   grant.b.edwardsYow! Excuse me, but didn't
  at   I tell you there's NO HOPE
  gmail.comfor the survival of OFFSET
   PRINTING?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: even faster heaps

[Sven R. Kunze]

On 06.03.2016 14:59, Sven R. Kunze wrote:
Using the original xheap benchmark 
, I could 
see huge speedups: from 50x/25x down to 3x/2x compared to heapq. 
That's a massive improvement. I will publish an update soon.


An here it is: http://srkunze.blogspot.com/2016/03/even-faster-heaps.html


Best,
Sven
--
https://mail.python.org/mailman/listinfo/python-list

[issue26520] asyncio.new_event_loop() hangs

[Guido van Rossum]

Guido van Rossum added the comment:

Why are you creating a new event loop for this purpose? There are all sorts of 
things that can go wrong with that.

This is not appropriate for a bug report, you should continue to seek help on 
StackOverflow.

--
resolution:  -> rejected
status: open -> closed

___
Python tracker 

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

it doesn't want to open

[mashaer elmekki]

Sent from Windows Mail
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: Adding Icon To Tkinter Window - Followup

[Joaquin Alzola]

>  root.wm_iconphoto(True, img)

What are the images format allowed?
This email is confidential and may be subject to privilege. If you are not the 
intended recipient, please do not copy or disclose its content but contact the 
sender immediately upon receipt.
-- 
https://mail.python.org/mailman/listinfo/python-list

pip install failure for cryptography, gnureadline

[Pietro Paolini]

Hi everybody,

I am not really familiar with the Py subsystem, even though I have got some
guidance from some colleague, I am getting stuck when installing a list of
packages contained in a file, running such command :


pip install -r /home/pietro/projects/cloud-provisioning/requirements.txt

Brings me :


Collecting docutils>=0.10 (from botocore<1.4.0,>=1.3.0->boto3==1.2.3->-r
/home/pietro/projects/cloud-provisioning/requirements.txt (line 9))
Building wheels for collected packages: cryptography, gnureadline
  Running setup.py bdist_wheel for cryptography: started
  Running setup.py bdist_wheel for cryptography: finished with status
'error'
  Complete output from command
/home/pietro/python-environment/cloud-provisioning-ve-2/bin/python -u -c
"import setuptools,
tokenize;__file__='/tmp/pip-build-pzgHry/cryptography/setup.py';exec(compile(getattr(tokenize,
'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))"
bdist_wheel -d /tmp/tmpoDkrDHpip-wheel- --python-tag cp27:
  running bdist_wheel
  running build
  running build_py
  creating build
  creating build/lib.linux-x86_64-2.7
  creating build/lib.linux-x86_64-2.7/cryptography
  copying src/cryptography/__init__.py ->
build/lib.linux-x86_64-2.7/cryptography
  copying src/cryptography/utils.py ->
build/lib.linux-x86_64-2.7/cryptography
  copying src/cryptography/x509.py ->
build/lib.linux-x86_64-2.7/cryptography
  copying src/cryptography/fernet.py ->
build/lib.linux-x86_64-2.7/cryptography
  copying src/cryptography/exceptions.py ->
build/lib.linux-x86_64-2.7/cryptography
  copying src/cryptography/__about__.py ->
build/lib.linux-x86_64-2.7/cryptography
  creating build/lib.linux-x86_64-2.7/cryptography/hazmat
  copying src/cryptography/hazmat/__init__.py ->
build/lib.linux-x86_64-2.7/cryptography/hazmat
  creating build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives
  copying src/cryptography/hazmat/primitives/interfaces.py ->
build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives
  copying src/cryptography/hazmat/primitives/__init__.py ->
build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives
  copying src/cryptography/hazmat/primitives/serialization.py ->
build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives
  ography/hazmat/backends/commoncrypto
  copying src/cryptography/hazmat/backends/commoncrypto/hashes.py ->
build/lib.linux-x86_64-2.7/cryptography/hazmat/backends/commoncrypto
  copying src/cryptography/hazmat/backends/commoncrypto/hmac.py ->
build/lib.linux-x86_64-2.7/cryptography/hazmat/backends/commoncrypto
  copying src/cryptography/hazmat/backends/commoncrypto/backend.py ->
build/lib.linux-x86_64-2.7/cryptography/hazmat/backends/commoncrypto
  running egg_info
  writing requirements to src/cryptography.egg-info/requires.txt
  writing src/cryptography.egg-info/PKG-INFO
  writing top-level names to src/cryptography.egg-info/top_level.txt
  writing dependency_links to src/cryptography.egg-info/dependency_links.txt
  writing entry points to src/cryptography.egg-info/entry_points.txt
  warning: manifest_maker: standard file '-c' not found
  []
  reading manifest file 'src/cryptography.egg-info/SOURCES.txt'
  reading manifest template 'MANIFEST.in'
  no previously-included directories found matching 'docs/_build'
  warning: no previously-included files matching '*' found under directory
'vectors'
  writing manifest file 'src/cryptography.egg-info/SOURCES.txt'
  creating build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives/src
  copying src/cryptography/hazmat/primitives/src/constant_time.c ->
build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives/src
  copying src/cryptography/hazmat/primitives/src/constant_time.h ->
build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives/src
  creating
build/lib.linux-x86_64-2.7/cryptography/hazmat/bindings/__pycache__
  copying
src/cryptography/hazmat/bindings/__pycache__/_Cryptography_cffi_590da19fxffc7b1ce.c
-> build/lib.linux-x86_64-2.7/cryptography/hazmat/bindings/__pycache__
  copying
src/cryptography/hazmat/bindings/__pycache__/_Cryptography_cffi_8f86901cxc1767c5a.c
-> build/lib.linux-x86_64-2.7/cryptography/hazmat/bindings/__pycache__
  copying
src/cryptography/hazmat/bindings/__pycache__/_Cryptography_cffi_d5a71fe5xf53f5318.c
-> build/lib.linux-x86_64-2.7/cryptography/hazmat/bindings/__pycache__
  running build_ext
  building '_Cryptography_cffi_d5a71fe5xf53f5318' extension
  creating build/temp.linux-x86_64-2.7
  creating build/temp.linux-x86_64-2.7/src
  creating build/temp.linux-x86_64-2.7/src/cryptography
  creating build/temp.linux-x86_64-2.7/src/cryptography/hazmat
  creating build/temp.linux-x86_64-2.7/src/cryptography/hazmat/bindings
  creating
build/temp.linux-x86_64-2.7/src/cryptography/hazmat/bindings/__pycache__
  x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g
-fstack-protector-strong -Wformat -Werror=format-security -fPIC
-I/usr/include/python2.7 -c

Re: even faster heaps

[Sven R. Kunze]

On 08.03.2016 08:12, srinivas devaki wrote:

Hi,
sorry i didn't get to your last mail as i'm having exams at that time.


No problem. :) I hope they went all well for you.


Everything is good so far.

but if at all the purpose is to add features to the stdlib heap and
keeping the speed offered by the stdlib, why aren't you allowing the
duplicate elements which is possible with stdlib heap.


Don't let the old boy have time to rest, he? ;-)

But that's good. We all need a kick in the ass from time to time in 
order to get thing running. :-)



to be able to add duplicate elements you just have to make the set as
a dict with counter as the value. afterall it is highly common to have
priority task scheduling with equal priorities to the tasks.

as far as the benchmarks are concerned it didn't change much with the
current dataset. but it is not valid to compare them as the current
dataset is intended for unique elements. but with the dict the dataset
can contain elements which have equal keys.


So, my initial design idea was to wrap these items up in their own 
wrapper and thus avoiding the duplicate issue. I discussed this with Cem 
here http://code.activestate.com/lists/python-list/697567/  :)



on my machine with 10 repetitions in the test_xheap_time.py
** results for the code which supports duplicate elements
h...@github.com/eightnoteight/xheap **

(u'init', u'heapq  ', u' 0.45 ( 1.00x)  4.59 ( 1.00x) 52.24 (
1.00x) 553.80 ( 1.00x)')
(u'', u'Heap   ', u' 0.48 ( 1.07x)  5.41 ( 1.18x) 75.89 (
1.45x) 786.46 ( 1.42x)')
(u'', u'RemovalHeap', u' 0.86 ( 1.93x)  9.98 ( 2.18x) 131.28 (
2.51x) 1364.14 ( 2.46x)')

(u'pop ', u'heapq  ', u' 0.09 ( 1.00x)  1.27 ( 1.00x) 15.64 (
1.00x) 184.76 ( 1.00x)')
(u'', u'Heap   ', u' 0.10 ( 1.07x)  1.33 ( 1.05x) 16.30 (
1.04x) 191.43 ( 1.04x)')
(u'', u'RemovalHeap', u' 0.15 ( 1.64x)  1.87 ( 1.47x) 21.33 (
1.36x) 242.31 ( 1.31x)')

(u'push', u'heapq  ', u' 0.04 ( 1.00x)  0.33 ( 1.00x)  3.53 (
1.00x) 32.99 ( 1.00x)')
(u'', u'Heap   ', u' 0.05 ( 1.20x)  0.41 ( 1.25x)  4.37 (
1.24x) 44.14 ( 1.34x)')
(u'', u'RemovalHeap', u' 0.06 ( 1.58x)  0.56 ( 1.70x)  5.85 (
1.66x) 59.59 ( 1.81x)')


(u'init', u'heapq', u' 0.45 ( 1.00x)  8.00 ( 1.00x) 109.50 (
1.00x) 898.50 ( 1.00x)')
(u'', u'OrderHeap', u' 0.50 ( 1.10x)  8.75 ( 1.09x) 112.63 (
1.03x) 1108.26 ( 1.23x)')
(u'', u'XHeap', u' 0.93 ( 2.06x) 13.88 ( 1.74x) 170.97 (
1.56x) 1709.94 ( 1.90x)')

(u'pop ', u'heapq', u' 0.04 ( 1.00x)  0.54 ( 1.00x)  6.50 ( 1.00x)
76.64 ( 1.00x)')
(u'', u'OrderHeap', u' 0.06 ( 1.73x)  0.80 ( 1.49x)  9.16 ( 1.41x)
101.68 ( 1.33x)')
(u'', u'XHeap', u' 0.10 ( 2.65x)  1.14 ( 2.13x) 12.60 ( 1.94x)
137.73 ( 1.80x)')

(u'push', u'heapq', u' 0.01 ( 1.00x)  0.17 ( 1.00x)  1.86 ( 1.00x)
14.85 ( 1.00x)')
(u'', u'OrderHeap', u' 0.04 ( 3.88x)  0.47 ( 2.86x)  4.80 ( 2.58x)
42.98 ( 2.89x)')
(u'', u'XHeap', u' 0.04 ( 3.79x)  0.47 ( 2.85x)  4.85 ( 2.61x)
43.94 ( 2.96x)')


(u'remove', u'RemovalHeap', u' 0.07 ( 1.00x)  0.73 ( 1.00x)  7.38 (
1.00x) 75.18 ( 1.00x)')
(u'  ', u'XHeap  ', u' 0.05 ( 0.79x)  0.55 ( 0.75x)  5.52 (
0.75x) 55.08 ( 0.73x)')




** benchmark for current git HEAD d0707fba2401a3cef8aed54028fe6d7e9497faa5 **


(u'init', u'heapq  ', u' 0.49 ( 1.00x)  5.03 ( 1.00x) 58.71 (
1.00x) 600.91 ( 1.00x)')
(u'', u'Heap   ', u' 0.51 ( 1.05x)  5.83 ( 1.16x) 82.88 (
1.41x) 886.22 ( 1.47x)')
(u'', u'RemovalHeap', u' 0.58 ( 1.19x)  7.19 ( 1.43x) 106.80 (
1.82x) 1108.52 ( 1.84x)')

(u'pop ', u'heapq  ', u' 0.10 ( 1.00x)  1.41 ( 1.00x) 17.64 (
1.00x) 209.82 ( 1.00x)')
(u'', u'Heap   ', u' 0.11 ( 1.07x)  1.47 ( 1.04x) 18.27 (
1.04x) 215.14 ( 1.03x)')
(u'', u'RemovalHeap', u' 0.15 ( 1.52x)  1.91 ( 1.35x) 22.64 (
1.28x) 258.68 ( 1.23x)')

(u'push', u'heapq  ', u' 0.04 ( 1.00x)  0.32 ( 1.00x)  3.49 (
1.00x) 33.92 ( 1.00x)')
(u'', u'Heap   ', u' 0.05 ( 1.18x)  0.39 ( 1.22x)  4.21 (
1.20x) 42.03 ( 1.24x)')
(u'', u'RemovalHeap', u' 0.06 ( 1.52x)  0.52 ( 1.62x)  5.60 (
1.60x) 56.54 ( 1.67x)')

Re: turtle ??

[MRAB]

On 2016-03-09 11:55, Steven D'Aprano wrote:

On Wed, 9 Mar 2016 08:06 pm, Peter Otten wrote:


Ömer sarı wrote:


l would like to ask a question as l m a little bit confused .


In computing details matter, and in communication odd personal habits
distract from the actual message. Please reconsider your use of an "l" as
a replacement for "I".


While I don't disagree, it is possible that Ömer sarı is typing on a
keyboard that doesn't have an I, or makes it difficult to use. The last
letter of his(?) name is LATIN SMALL LETTER DOTLESS I, which suggests
possibly a Turkish or Armenian keyboard. I don't know how easy it is to get
I as opposed to İ (LATIN CAPITAL LETTER I WITH DOT ABOVE). So we might like
to give him a little slack.

But apart from that, I agree: in the long term, if Ömer is going to be
programming, he'll need to do something about that keyboard.


FYI, the uppercase of "ı" is "I" and the lowercase of "İ" is "i".

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

[issue26520] asyncio.new_event_loop() hangs

[Erwin Mayer]

Erwin Mayer added the comment:

This cannot be a firewall issue as a loop can be successfully created thousands 
of time, for hours, before a creation attempt will hang (with no change from 
the firewall). The rest of the program (other threads) continues to run and 
there is memory issue.

If I understand correctly, the sockets used by asyncio are internal only and 
would not be exposed to the world through any local port, so I don't see how a 
firewall could intercept them (that would be worrisome for all users of 
asyncio).

--

___
Python tracker 

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

[issue26519] Cython doesn't work anymore on Python 3.6

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Cython 0.23.4 was released at 2015-10-10. The fix was applied 2016-01-16. Try 
to use Cython from trunk. May be this is not exactly the same bug and Cython 
needs other fix.

The change is deliberate. It helps to find existing bugs.

Except trivial case when your extension class has no any fields in additional 
to pickleable parent class, the class needs to provide some combinations of 
__getstate__, __setstate__, __getnewargs__/__getnewargs_ex__ and 
__reduce__/__reduce_ex__ to be pickleable. This was said in PEP 307. Previously 
you silently produced invalid pickle and got an exception or invalid object 
when unpickle it. Now you more likely get an exception at pickling time.

--

___
Python tracker 

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

[issue26249] Change PyMem_Malloc to use pymalloc allocator

[Yury Selivanov]

Changes by Yury Selivanov :


--
nosy:  -Yury.Selivanov, yselivanov

___
Python tracker 

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

Re: Public Service Announcement: planetpython.org

[Mark Lawrence]

On 09/03/2016 15:27, Tim Golden wrote:

For those who didn't know, we have a feed aggregator at
https://planetpython.org. We're trying to clean up out-of-date or
incorrect feed URLs.



This is available from news.gmane.org as gwene.org.python.planet

I just wish that I'd found out about the one stop shop that is gmane 
years before I acually did.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

[issue26249] Change PyMem_Malloc to use pymalloc allocator

[STINNER Victor]

STINNER Victor added the comment:

2016-03-09 18:28 GMT+01:00 Antoine Pitrou :
> Does the API doc say anything about the GIL, for example? Or Valgrind?

For the GIL, yes, Python 3 doc is explicit:
https://docs.python.org/dev/c-api/memory.html#memory-interface

Red and bold warning: "The GIL must be held when using these functions."

Hum, sadly it looks like the warning miss in Python 2 doc.

The GIL was the motivation to introduce the PyMem_RawMalloc() function
in Python 3.4.

For Valgrind: using the issue #26516, you will be able to use
PYTHONMALLOC=malloc to use easily Valgrind even on a Python compiled
in release mode (which is a new feature, before you had to manually
recompile Python in debug mode with --with-valgrind)).

--

___
Python tracker 

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

[issue26249] Change PyMem_Malloc to use pymalloc allocator

[STINNER Victor]

STINNER Victor added the comment:

cryptography: good

* Git commit 0681de7241dcbaec7b3dc85d3cf3944e4bec8309 (Mar 9 2016)

"4 failed, 77064 passed, 3096 skipped in 405.09 seconds" 

1 error is related to the version number (probably an issue on how I run the 
tests), 3 errors are FileNotFoundError related to cryptography_vectors. At 
least, there is no Python fatal error related to memory allocators ;-)

--

Hum, just in case, I checked my venv:

(ENV) haypo@smithers$ python -c 'import _testcapi; _testcapi.pymem_api_misuse()'
...
Fatal Python error: bad ID: Allocated using API 'o', verified using API 'r'

(ENV) haypo@smithers$ python -c 'import _testcapi; 
_testcapi.pymem_buffer_overflow()'
...
Fatal Python error: bad trailing pad byte

It works ;-)

--

___
Python tracker 

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

[issue26249] Change PyMem_Malloc to use pymalloc allocator

[Antoine Pitrou]

Antoine Pitrou added the comment:

Le 09/03/2016 18:27, STINNER Victor a écrit :
> 
> I disagree on the fact that my change breaks any API. The API doc is
clear.

Does the API doc say anything about the GIL, for example? Or Valgrind?

> I suggest you to continue the discussion on python-dev for a wider
audience. I will test a few more projects before replying on the
python-dev thread.

I have no interest in going back and forth between the Python tracker
and python-dev (especially since I hardly read python-dev these days).
If you address my questions positively here I will be happy with the patch!

--

___
Python tracker 

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

[issue26249] Change PyMem_Malloc to use pymalloc allocator

[STINNER Victor]

STINNER Victor added the comment:

> I'm talking about the performance improvement in third-party libraries, not 
> the performance improvement in CPython itself which can be addressed by 
> replacing the internal API calls.

Oh ok. I don't know how to measure the performance of third-party libraries. I 
expect no speedup or a little speedup, but no slow-down.


> Do you think it's reasonable to risk breaking external libraries just
for a hypothetic "performance improvement"?

The question is if my change really breaks anything in practice. I'm testing 
some popular C extensions to prepare an answer. Early results is that developer 
use correctly the Python allocator API :-)

I disagree on the fact that my change breaks any API. The API doc is clear. For 
example, you must use PyMem_Free() on memory allocated by PyMem_Malloc(). If 
you use free(), it fails badly with Python compiled in debug mode.

My issue #26516 "Add PYTHONMALLOC env var and add support for malloc debug 
hooks in release mode" may help developers to validate their own application.

I suggest you to continue the discussion on python-dev for a wider audience. I 
will test a few more projects before replying on the python-dev thread.

--

___
Python tracker 

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

[issue26249] Change PyMem_Malloc to use pymalloc allocator

[Antoine Pitrou]

Antoine Pitrou added the comment:

> Yes. It was discussed in the python-dev thread.

I'm talking about the performance improvement in third-party libraries, not the 
performance improvement in CPython itself which can be addressed by replacing 
the internal API calls.

--

___
Python tracker 

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

[issue26249] Change PyMem_Malloc to use pymalloc allocator

[STINNER Victor]

STINNER Victor added the comment:

> Define "slow".  malloc() on Linux should be reasonably fast.

See first messages of this issue for benchmark results. Some specific 
benchmarks are faster, none is slower.


> Do you think it's reasonable to risk breaking external libraries just
for a hypothetic "performance improvement"?

Yes. It was discussed in the python-dev thread.

--

___
Python tracker 

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

[issue26249] Change PyMem_Malloc to use pymalloc allocator

[Antoine Pitrou]

Antoine Pitrou added the comment:

Le 09/03/2016 18:01, STINNER Victor a écrit :
> I don't understand why we should keep a slow allocator if Python has a faster 
> allocator?

Define "slow".  malloc() on Linux should be reasonably fast.

Do you think it's reasonable to risk breaking external libraries just
for a hypothetic "performance improvement"?

Again, why don't you try simply changing internal calls?

--

___
Python tracker 

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

[issue26249] Change PyMem_Malloc to use pymalloc allocator

[STINNER Victor]

STINNER Victor added the comment:

Pillow: good

Note: I had to install JPEG headers (sudo dnf install -y libjpeg-turbo-devel).

Tested version: git commit 44c5cfc3874deaac9cfa87780822ee714c0d (Mar 8 
2016).

---
Pillow$ python setup.py install
Pillow$ python selftest.py
Pillow$ python  test-installed.py
(...)
Ran 671 tests in 8.458s

FAILED (SKIP=124, errors=2)
---

The two errors are "OSError: decoder libtiff not available".

--

___
Python tracker 

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

Re: Adding Icon To Tkinter Window - Followup

[Serhiy Storchaka]

On 06.03.16 18:30, Wildman via Python-list wrote:

That does not work...

$ ./makexface.py
Traceback (most recent call last):
   File "./makexface.py", line 236, in 
 root.wm_iconphoto(True, img)
   File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 1897, in __getattr__
 return getattr(self.tk, attr)
AttributeError: wm_iconphoto


This works in Python 3.x. In 2.7 you should use

root.tk.call('wm', 'iconphoto', str(root), '-default', img, ...)

Note that it is worth to specify images for several different sizes (up 
to 128x128 for OS X).


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

[issue26513] platform.win32_ver() broken in 2.7.11

[Steve Dower]

Steve Dower added the comment:

That's what I initially assumed, but when I looked in my 2.7 repo those changes 
weren't there. But according to the bug I checked them in, so I guess it is my 
fault.

Looking at the diff (e.g. 2f57270374f7), it seems I got sucked in by following 
the old code that tried to get `sys.getwindowsversion().platform_type`, when it 
should have been `platform`. (Possibly this was changed late during review, as 
I definitely tested on at least one server platform to verify... maybe it 
worked with the old fallback code and then once I made sure that we always set 
`platform` I removed the fallback without fixing the attribute.)

The patch is simple enough - committing and merging branches is the hard part. 
When I get a few free minutes I'll fix the attribute.

--
assignee:  -> steve.dower
type:  -> behavior
versions: +Python 3.5, Python 3.6

___
Python tracker 

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

[issue26249] Change PyMem_Malloc to use pymalloc allocator

[STINNER Victor]

STINNER Victor added the comment:

Antoine Pitrou added the comment:
> Victor, why do you insist on this instead of changing internal API calls in 
> CPython?

https://mail.python.org/pipermail/python-dev/2016-February/143097.html

"There are 536 calls to the functions PyMem_Malloc(), PyMem_Realloc()
and PyMem_Free()."

--

___
Python tracker 

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

[issue26249] Change PyMem_Malloc to use pymalloc allocator

[STINNER Victor]

STINNER Victor added the comment:

lxml: good!

* I patched Python 3.6 with pymem.patch of this issue + pymem-3.patch of issue 
#26516
* Tested lxml version: git commit 93ec66f6533995a7742278f9ba14b925149ac140 (Mar 
8 2016)

lxml$ make test
(...)
Ran 1735 tests in 27.663s

OK

--

___
Python tracker 

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

[issue26249] Change PyMem_Malloc to use pymalloc allocator

[Antoine Pitrou]

Antoine Pitrou added the comment:

> "There are 536 calls to the functions PyMem_Malloc(), PyMem_Realloc()
and PyMem_Free()."

I'm sure you can use powerful tools such as "sed" ;-)

--

___
Python tracker 

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

[issue26249] Change PyMem_Malloc to use pymalloc allocator

[STINNER Victor]

STINNER Victor added the comment:

> I'm sure you can use powerful tools such as "sed" ;-)

I guess that PyMem functions are used in third party C extensions modules. I 
expect (minor) speedup in these modules too.

I don't understand why we should keep a slow allocator if Python has a faster 
allocator?

--

___
Python tracker 

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

[issue26249] Change PyMem_Malloc to use pymalloc allocator

[STINNER Victor]

STINNER Victor added the comment:

numpy: good!

* I patched Pyhon 3.6 with pymem.patch of this issue + pymem-3.patch of issue 
#26516
* I had issues to run tests with Python 3.6 compiled in debug mode: 
http://bugs.python.org/issue26519 & https://github.com/numpy/numpy/issues/7399
* I ran the test suite: all tests pass, no bug related to memory allocators
* Tested numpy version: commit b92cc76afad2e74cbbf6f5b9f5b68050f7c8642a (Mar 7 
2016)

Commands ran in numpy tests in a virtual environment:

numpy$ python setup.py install
numpy$ cd..
$ python -c 'import numpy; numpy.test()'
(...)
Ran 6206 tests in 280.986s

OK (KNOWNFAIL=7, SKIP=6)

--

___
Python tracker 

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

[issue26249] Change PyMem_Malloc to use pymalloc allocator

[Antoine Pitrou]

Antoine Pitrou added the comment:

Victor, why do you insist on this instead of changing internal API calls in 
CPython?

--

___
Python tracker 

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

Re: Pyhon 2.x or 3.x, which is faster?

[Steven D'Aprano]

On Wed, 9 Mar 2016 11:53 pm, Marko Rauhamaa wrote:

> It came off as standard schoolyard bullying.

You must have lived a privileged life if you think a little sarcasm is what
school bullies do.

If we're going to exchange pop psychology tales, I don't know what it's like
for young girls, but in my experience when it comes to boys sarcasm is far
more likely to be used by the *victims* of bullying as a (pathetically
ineffective) defence mechanism.

Of course, things may be different on the Internet. Bullies cannot, as a
rule, punch you in the face and stomp on your lunch like they can in the
schoolyard, so perhaps they have learned to co-opt the tactics of their
erstwhile victims.


>If your child often tries to explain away misdeeds with 'We were just
>having fun ...', [...] you may just have a bully in the making living
>under your roof.

They might even be a psychopath. They could even grow up to be a serial
killer! Why, they might even be the next Hitler!!! Better drown them in the
bathtub now, before they kill 6 million people and start a world war!!!1!

Or... maybe they actually were just having fun, just like they said, and the
parents are over-protective, over-suspicious, over-reacting killjoys who
misinterpret the rough and tumble of play as abuse.


>> Even if I used ... sarcasm.
> 
>The dictionary defines Sarcasm as: "The use of irony to mock or
>convey contempt"

Well duh. I was mocking and conveying my contempt of Bart's error handling
code ("sys.exit()"). Wasn't that obvious? Perhaps I could add some markup
next time:


"Brilliant! I love code like this!"


Or do you think it would sting less if I were merely brutally honest?

"Your code is bad and you should feel bad for having written it."

Or perhaps "If you were a student of mine, I would fail you for that code."

Or perhaps you think I should have given him an A+ and an elephant stamp for
effort? "We're all winners here, yay!"


I think Bart made the right response under the circumstances: he pointed out
that his code was obviously quick and dirty code for testing purposes and
not intended as production code, and he mocked me for not having noticed
this fact, as he was completely right to do. But I was mislead by his
earlier comments, and thought that it was production code (even if his
user-base consisted of just one person, himself).



-- 
Steven

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

Re: Pyhon 2.x or 3.x, which is faster?

[BartC]

On 09/03/2016 14:57, Steven D'Aprano wrote:

On Thu, 10 Mar 2016 01:11 am, Chris Angelico wrote:


The first three bytes are the "UTF-8 BOM", which suggests you may have
created this in a broken editor like Notepad.


Notepad may be horribly crippled, but I'm not entirely sure "broken" is the
right word for it. Does it do anything *wrong*? I don't think so.


(Well, it's quite difficult to get it to save to the right filename (it 
insists on sticking ".txt" on the end even when the file name already 
has an extension).


And if you're not looking, it will 'Save As' in some arbitrary 
directory, because it remembers it from the last time you used it a 
month ago for a different project and in a different location. Very 
puzzling when you try and load it again and it's nowhere to be seen!


It doesn't occur it to use to use the same directory it's just loaded a 
file from as a default.


But it does have a reasonable choice of output encodings.)

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

Re: Adding Icon To Tkinter Window

[Rick Johnson]

On Saturday, March 5, 2016 at 3:39:00 PM UTC-6, Terry Reedy wrote: 
> No single simple statement work for all situations.  You should have 
> specified OS, Python version, and tcl/tk version.  (IDLE's Help -> About 
> IDLE displays full tk version).

Yes, because Tkinter is not as cross-platform as it's hyped to be.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue26519] Cython doesn't work anymore on Python 3.6

[STINNER Victor]

STINNER Victor added the comment:

> This was a bug in Cython and it is fixed now.

If the change is deliberate, can you please mention it in "What's New in Python 
3.6" doc? Especially in the "Porting to Python 3.6" section:
https://docs.python.org/dev/whatsnew/3.6.html#porting-to-python-3-6

Can you suggest a fix in the doc? I guess that a method should be added: 
__reduce__(), __reduce_ex__() or __getstate__()?

--

___
Python tracker 

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

[issue26520] asyncio.new_event_loop() hangs

[STINNER Victor]

STINNER Victor added the comment:

Do you have a firewall? Maybe the firewall blocks programs listening on 
sockets? It would be silly, the socket is only listening on 127.0.0.1 (local 
link) (or ::1 in IPv6, also local link).


Extract of the socketpair() function:

try:
csock.connect((addr, port))
except (BlockingIOError, InterruptedError):
pass

Can you please try to replace this code with:

try:
csock.connect((addr, port))
except (BlockingIOError, InterruptedError) as exc:
print("CONNECT ERROR! %r" % (exc,))

You can copy socket.py from the Python standard library to the current 
directory and modify the local copy.

--

___
Python tracker 

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

Re: Adding Icon To Tkinter Window

[Rick Johnson]

On Saturday, March 5, 2016 at 12:08:27 PM UTC-6, Grant Edwards wrote:
> You'll have to be a lot more specific about what you mean by "add an
> icon to a window".  Do you just want to display an .ico file within a
> window?

I think he wants to use his *OWN* icon on a window's title bar, instead of the 
default icon that Tkinter uses. It would help if he posted the code he tried, 
along with any exceptions that were raised. 
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue26519] Cython doesn't work anymore on Python 3.6

[STINNER Victor]

STINNER Victor added the comment:

"May be this is the same issue as reported in msg257646. This was a bug in 
Cython and it is fixed now."

Oh, I wasn't aware of the issue #22995. I will read it.

The bug isn't fixed yet in the latest release of Cython (0.23.4, released at 
2015-10-10). I guess that it's fixed in the development version.

--

___
Python tracker 

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

[ANN] First PyCon Israel (May 2,3)

[Miki Tebeka]

Greetings,

The first PyCon Israel is happening! It's taking place on May 2-3, 2016, will 
be attended by hundreds of Pythonistas, and is sponsored by major international 
and local companies that use Python as part of their daily work.

CFP is open, please head over to http://il.pycon.org/2016/ to see more details.

See you there,
--
Miki
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: A mistake which almost went me mad

[Rick Johnson]

On Thursday, March 3, 2016 at 4:22:07 AM UTC-6, ast wrote:
> Hello
> 
> This has to be told
> 
> I created a file pickle.py in order to test some files
> read/write with objects and put it in a directory
> which is on my python path. 
> 
> Then the nightmare began
> 
> - Idle no longer works, window no longer opens 
> when double clicked, no errors messsages
> 
> - python -m pip list doesnt work, crash with an 
> error message related to pickle
> 
> I uninstalled python34 and reinstalled it, same problem
> I uninstalled python34 and instaled 3.5, same problem
> 
> ...
> 
> I finally understood that pickle.py is the name of the file
> containing the official pickle module.
> 
> This module is probably used by various python programs,
> IDLE, pip ...
> 
> Instead of reading official pickle, python read my file ...

This is a design flaw of the python language. If all standard library modules 
would have been protected from the global namespace by a single symbol -- say 
"stdlib" or "py" or whatever -- we would only need to avoid *ONE* symbol, 
instead of hundreds of them!!! Third party modules should have their own 
namespace as well. 

 from stdlib import re
 from stdlib.re import search
 from extlib import PIL
 from extlib.PIL import Image, ImageTk

Since those responsible for this flaw are unable, or unwilling, to fix it, the 
only solution for *YOU* is to (1) memorize every module name that exists in the 
python standard library, and also those that exist in your "site-packages" 
directory, or (2) hide all your personal modules behind a single symbol by 
utilizing a package.
 
 +mylib
   __init__.py
   pickle.py

import mylib.pickle as mypickle
mypickle.do_something()

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