[issue38728] Update PC/pyconfig.h to support disabling auto linking

[Jean-Christophe Fillion-Robin]

Jean-Christophe Fillion-Robin  added the comment:

Associated pull request has been updated, CLA signed and it is ready for final 
review and integration.

Thanks so much for your time,

--

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

[issue40127] Documentation of SSL library

[Christophe Nanteuil]

Christophe Nanteuil  added the comment:

I modified the PR according to the source code: 
"if all three are None and SSLContext.verify_mode is not set to CERT_NONE, this 
function uses the system's default CA certificates."

The way the system is configured may depend on multiple parameters but I hope 
this statement is clearer and it disturbs me to read that the function "can 
choose", all the more for a security module.

--

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

[issue40127] Documentation of SSL library

[Christophe Nanteuil]

Christophe Nanteuil  added the comment:

Thanks for clarifying the choice. I understand that we could state :
" if cafile ... are None, the function falls back to user/system configuration 
(which is beyond this documentation)."

--

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

[issue40127] Documentation of SSL library

[Christophe Nanteuil]

Change by Christophe Nanteuil :


--
keywords: +patch
pull_requests: +18611
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19253

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

[issue40127] Documentation of SSL library

[Christophe Nanteuil]

Change by Christophe Nanteuil :


--
type:  -> enhancement

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

[issue40127] Documentation of SSL library

[Christophe Nanteuil]

New submission from Christophe Nanteuil :

For the ssl.create_default_context() function, it states that, "if cafile, 
capath and cadata are None, the function *can* choose to trust the system's 
default CA certificates instead".
This statement is not clear as, if the values are None, there is no choice and 
the only elements available are system's default CA.
AFAIK, if the values are not None, it will not fall back to system's default CA 
even if the given CA does not match.
I propose to modify the end of the sentence with "the function trusts the 
system's default CA certificates instead".

--
assignee: docs@python
components: Documentation
messages: 365398
nosy: Christophe Nanteuil, docs@python
priority: normal
severity: normal
status: open
title: Documentation of SSL library
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

[issue38728] Update PC/pyconfig.h to support disabling auto linking

[Jean-Christophe Fillion-Robin]

Jean-Christophe Fillion-Robin  added the comment:

PY_NO_LINK_LIB will work well. I will work on a patch later this week.

--

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

[issue38728] Update PC/pyconfig.h to support disabling auto linking

[Jean-Christophe Fillion-Robin]

New submission from Jean-Christophe Fillion-Robin :

When configuring project using build-system generator like CMake, the linking 
is explicitly handled and does not to be implicitly hard-coded in pyconfig.h

Having the "pythonXY.lib" library hard-coded in pyconfig.h currently requires 
to explicitly specify a link directory. While possible, this require to 
increase the complexity of our build-system.

I suggest we introduce a new macro (e.g PY_CONFIG_AUTOLINK_DISABLED)

--
components: Windows
messages: 356158
nosy: Jean-Christophe Fillion-Robin, paul.moore, steve.dower, tim.golden, 
zach.ware
priority: normal
severity: normal
status: open
title: Update PC/pyconfig.h to support disabling auto linking
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

[asyncio] Suggestion for a major PEP

[Christophe Bailly]

Hello,

I copy paste the main idea from an article I have written:
contextual async


"

Imagine you have some code written for monothread. And you want to include
your code in a multithread environment.  Do you need to adapt all your code
which is what you do when you want to migrate to async code ? The answer is
no.

Functionnally these constraints are not justified neither technically

Do we have the tools to do this ? Yes because thanks to boost::context we
can switch context between tasks. When a task suspends, it just calls a
function (the event loop or reactor) to potentially switch to another task.
Just like threads switch contexts…

Async/Await logic has introduced a symetric relation wich introduces
unnecessary contraints. We should just the same logic as thread logic.

"

Read the examples in the article I have developped a prototype in C++ and
everything works perfectly.

My opinion is that sooner or later, it will have to switch to this logic
because chaining async/aswait is a huge contraints and does not make sense
in my opinion.

Maybe I am missing something,

Feel free to give me your feedback.

Regards,


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

[issue34158] Documentation of datetime '%z' format code is odd

[Christophe Nanteuil]

Christophe Nanteuil  added the comment:

PR updated according to Martin Panter comments.

--

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

[issue34158] Documentation of datetime '%z' format code is odd

[Christophe Nanteuil]

New submission from Christophe Nanteuil :

In § 8.1.8. "strftime() and strptime() Behavior", the documentation states that 
"%z" format code is a string of the form '±HHMM[SS[.uu]]' where uu is a 
2-digit string giving the number of UTC offset microseconds.
I think it's a 6-digit string.

--
assignee: docs@python
components: Documentation
files: datetime.rst.patch
keywords: patch
messages: 321968
nosy: Christophe Nanteuil, docs@python
priority: normal
severity: normal
status: open
title: Documentation of datetime  '%z' format code is odd
versions: Python 3.7
Added file: https://bugs.python.org/file47704/datetime.rst.patch

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

[issue24132] Direct sub-classing of pathlib.Path

[Christophe BAL]

Christophe BAL <projet...@gmail.com> added the comment:

Hello.

What about AbstractPath instead of _PurePath ?

Le 28/03/2018 à 02:30, qb-cea a écrit :
> qb-cea <quentin.bou...@cea.fr> added the comment:
>
> Hi all,
>
> I made a pull request proposing a fix for this issue. There is still quite a 
> lot to be done:
>   - I exposed some variables (and probably methods too) that used to be 
> hidden;
>   - I did not update the documentation;
>   - I did not add a proper test.
>
> I will try to fix those by the end of the week.
>
> The patch mainly consists of two things:
>   - having Path (resp. PurePath) be a variable pointing at either 
> (Pure)PosixPath or (Pure)WindowsPath, depending on the platform (like Kevin 
> Norris suggested);
>   - introducing two new abstract classes _PurePath and ConcretePath from 
> which PurePosixPath, PureWindowsPath and PosixPath, WindowsPath classes 
> inherit;
>   - removing the _Flavor classes, and redistributing their method to 
> platform-specific classes.
>
> Ideally I would like _PurePath to become a public class, but I could not come 
> up with a proper name. Any feedback is more than welcome =]
>
> --
>
> ___
> Python tracker <rep...@bugs.python.org>
> <https://bugs.python.org/issue24132>
> ___

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue24132>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24132] Direct sub-classing of pathlib.Path

[Christophe BAL]

Christophe BAL <projet...@gmail.com> added the comment:

Mistyping : /search for class PPath/ with two P.

Le 08/11/2017 à 13:59, Christophe BAL a écrit :
> Christophe BAL <projet...@gmail.com> added the comment:
>
> For the moment, you can take a look at this little script that acheives
> subclassing of Path :
> https://github.com/bc-python/mistool/blob/master/mistool/os_use.py
> (search for class Path).
>
> Le 08/11/2017 à 09:55, Paul Moore a écrit :
>> Paul Moore <p.f.mo...@gmail.com> added the comment:
>>
>> @elguavas the problem is, no-one has proposed a patch. There's not likely to 
>> be much movement on this until someone provides one.
>>
>> --
>>
>> ___
>> Python tracker <rep...@bugs.python.org>
>> <https://bugs.python.org/issue24132>
>> ___
> --
>
> ___
> Python tracker <rep...@bugs.python.org>
> <https://bugs.python.org/issue24132>
> ___

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue24132>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24132] Direct sub-classing of pathlib.Path

[Christophe BAL]

Christophe BAL <projet...@gmail.com> added the comment:

For the moment, you can take a look at this little script that acheives 
subclassing of Path : 
https://github.com/bc-python/mistool/blob/master/mistool/os_use.py 
(search for class Path).

Le 08/11/2017 à 09:55, Paul Moore a écrit :
> Paul Moore <p.f.mo...@gmail.com> added the comment:
>
> @elguavas the problem is, no-one has proposed a patch. There's not likely to 
> be much movement on this until someone provides one.
>
> --
>
> ___
> Python tracker <rep...@bugs.python.org>
> <https://bugs.python.org/issue24132>
> ___

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue24132>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29884] faulthandler does not properly restore sigaltstack during teardown

[Christophe Zeitouny]

Changes by Christophe Zeitouny <ch...@tich.info>:


--
pull_requests: +704

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29884>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29884] faulthandler does not properly restore sigaltstack during teardown

[Christophe Zeitouny]

Changes by Christophe Zeitouny <ch...@tich.info>:


--
pull_requests: +703

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29884>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29884] faulthandler does not properly restore sigaltstack during teardown

[Christophe Zeitouny]

Changes by Christophe Zeitouny <ch...@tich.info>:


--
pull_requests: +682

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29884>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29884] faulthandler does not properly restore sigaltstack during teardown

[Christophe Zeitouny]

Changes by Christophe Zeitouny <ch...@tich.info>:


Added file: http://bugs.python.org/file46755/python_reproducer.cpp

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29884>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29884] faulthandler does not properly restore sigaltstack during teardown

[Christophe Zeitouny]

New submission from Christophe Zeitouny:

Looks like faulthandler is not properly tearing down its sigaltstack, causing 
potential double-free issues in any application that embeds the Python 
interpreter.
I stumbled upon this when I enabled AddressSanitizer on my application, which 
sets up and tears down a Python interpreter instance at runtime. 
AddressSanitizer complained about a double-free of the stack_t::ss_sp memory 
region.
After close inspection, here's what's happening:

1. When a new thread is created, AddressSanitizer sets up its own alternative 
stack by calling sigaltstack
2. Py_Initialize() is called, which initializes faulthandler, which sets up its 
own alternative stack, therefore overriding the one installed by 
AddressSanitizer
3. Py_Finalize() is called, which deinitializes faulthandler, which merely 
deletes the allocated stack region, but leaves the alternative stack installed. 
Any signal that occurs after this point will be using a memory region it 
doesn't own as stack. dangerous stuff.
4. The thread exits, at which point AddressSanitizer queries sigaltstack for 
the current alternative stack, blindly assumes that it's the same one that it 
installed, and attempts to free the allocated stack region. Therefore causing a 
double free issue

Regardless of the fact that AddressSanitizer should probably not blindly trust 
that the currently installed sigaltstack is the same one it installed earlier, 
the current code in faulthandler leaves the sigaltstack in a very bad state 
after finalizing.
This means that the application that embeds the Python interpreter better hope 
that no signals are raised after it calls Py_Finalize().

I have a patch that fixes this issue. faulthandler will save the previously 
installed alternative stack at initialization time. During deinitialization, it 
will query sigaltstack for the current stack. If it's the same as the one it 
installed,
it will restore the saved previous stack.

'sigaltstack' just sounds like a badly designed API. There is essentially no 
way to use it 'correctly'.
Here's how AddressSanitizer uses it (line 164): 
http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/sanitizer_common/sanitizer_posix_libcdep.cc?view=markup
and here's how the Chrome browser uses it: 
https://chromium.googlesource.com/breakpad/breakpad/+/chrome_43/src/client/linux/handler/exception_handler.cc#149

Notice that my approach is closer to what Chrome does, but in the case where 
the installed stack is no longer ours, I don't disable whatever stack is 
installed. This is because I don't believe that will make much difference. 
Whoever switched out the stack could have
saved our stack somewhere and planned on blindly restoring it upon exit. In 
which case, whatever we do would be overridden.

Attached are a tiny reproducer for the issue, along with the complete analysis 
of what's reported by AddressSanitizer. I'll follow this up by a pull request 
for my changes.

Thanks!
Chris

--
components: Extension Modules
files: python_failure.txt
messages: 290025
nosy: haypo, tich
priority: normal
severity: normal
status: open
title: faulthandler does not properly restore sigaltstack during teardown
type: enhancement
Added file: http://bugs.python.org/file46754/python_failure.txt

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29884>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24608] Certain inputs to wave.open() result in readframes returning a str instead of bytes

[Christophe Biocca]

New submission from Christophe Biocca:

Basically, some (malformed or empty?) WAV strings result in the empty string 
being returned when calling readframes.

That string cannot be passed back to writeframes() without causing a crash, 
since it does not implement the buffer interface.

--
components: Library (Lib)
files: python_wave_error.py
messages: 246575
nosy: Christophe Biocca
priority: normal
severity: normal
status: open
title: Certain inputs to wave.open() result in readframes returning a str 
instead of bytes
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file39891/python_wave_error.py

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

[issue24132] Direct sub-classing of pathlib.Path

[Christophe BAL]

Changes by Christophe BAL projet...@gmail.com:


--
title: Direct sub-classing of pathless.Path - Direct sub-classing of 
pathlib.Path

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

[issue24132] Direct sub-classing of pathlib.Path

[Christophe BAL]

Christophe BAL added the comment:

Hello.

I will give a real example in 5 hours after my job. I will try tomorrow a
solution to ease the subclassing using another dedicazted class PathPlus,
sorry for the name. The idea would be to use this new class for
customization, and also to define WindowsPath and PosixPath sub-classing
this new class. By default PathPlus would be an empty class. I do not know
if this works well. Maybe my idea is a bad one.

*Christophe BAL*
*Enseignant de mathématiques en Lycée **et développeur Python amateur*
*---*
*French math teacher in a Lycée **and **Python **amateur developer*

2015-05-06 13:05 GMT+02:00 Antoine Pitrou rep...@bugs.python.org:


 Antoine Pitrou added the comment:

 The Path classes were not designed to be subclassable by the user.
 I'm not against making subclassing easier, but someone will have to
 propose a viable approach for that.

 --
 versions: +Python 3.5 -Python 3.4

 ___
 Python tracker rep...@bugs.python.org
 http://bugs.python.org/issue24132
 ___


--

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

[issue24132] Direct sub-classing of pathlib.Path

[Christophe BAL]

Christophe BAL added the comment:

Here are for example two extra methods that I have implemented.

def __sub__(cls, path):

This magic method allows to use ``onepath - anotherpath`` instead of the
long
version ``onepath.relative_to(anotherpath)`` given by ``pathlib.Path``.

return cls.relative_to(path)

def _ppath_common_with(cls, paths):

This method returns the path of the smaller common folder of the current
path
and at least one paths.

python::
from mistool import os_use

path   = os_use.PPath(/Users/projects/source/doc)
path_1 = os_use.PPath(/Users/projects/README)
path_2 = os_use.PPath(/Users/projects/source/misTool/os_use.py)

print(path.common_with((path_1, path_2)))

if not isinstance(paths, (list, tuple)):
paths = [paths]

commonparts = list(cls.parts)

for onepath in paths:
i = 0

for common, actual in zip(commonparts, onepath.parts):
if common == actual:
i += 1
else:
break

commonparts = commonparts[:i]

if not commonparts:
break

commonpath = pathlib.Path()

for part in commonparts:
commonpath /= part

return commonpath

*Christophe BAL*
*Enseignant de mathématiques en Lycée **et développeur Python amateur*
*---*
*French math teacher in a Lycée **and **Python **amateur developer*

2015-05-06 14:13 GMT+02:00 Christophe BAL rep...@bugs.python.org:


 Christophe BAL added the comment:

 Hello.

 I will give a real example in 5 hours after my job. I will try tomorrow a
 solution to ease the subclassing using another dedicazted class PathPlus,
 sorry for the name. The idea would be to use this new class for
 customization, and also to define WindowsPath and PosixPath sub-classing
 this new class. By default PathPlus would be an empty class. I do not know
 if this works well. Maybe my idea is a bad one.

 *Christophe BAL*
 *Enseignant de mathématiques en Lycée **et développeur Python amateur*
 *---*
 *French math teacher in a Lycée **and **Python **amateur developer*

 2015-05-06 13:05 GMT+02:00 Antoine Pitrou rep...@bugs.python.org:

 
  Antoine Pitrou added the comment:
 
  The Path classes were not designed to be subclassable by the user.
  I'm not against making subclassing easier, but someone will have to
  propose a viable approach for that.
 
  --
  versions: +Python 3.5 -Python 3.4
 
  ___
  Python tracker rep...@bugs.python.org
  http://bugs.python.org/issue24132
  ___
 

 --

 ___
 Python tracker rep...@bugs.python.org
 http://bugs.python.org/issue24132
 ___


--

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

[issue24132] Direct sub-classing of pathlib.Path

[Christophe BAL]

Christophe BAL added the comment:

Are you the author of path lib ?

*Christophe BAL*
*Enseignant de mathématiques en Lycée **et développeur Python amateur*
*---*
*French math teacher in a Lycée **and **Python **amateur developer*

2015-05-06 21:01 GMT+02:00 Paul Moore rep...@bugs.python.org:


 Paul Moore added the comment:

 I have no problem with that - it's a style choice certainly.

 As I said, I'd like to see simpler subclassing of pathlib objects. I just
 think it'll be quite hard to do (given the complexities of classes for
 Windows/Unix as well as pure and concrete paths). So if it's just about
 examples like this, I personally would take the easier route and just go
 with standalone functions. If someone else felt strongly enough to design
 and implement a subclassing solution, that's fine though.

 --

 ___
 Python tracker rep...@bugs.python.org
 http://bugs.python.org/issue24132
 ___


--

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

[issue24132] Direct sub-classing of pathlib.Path

[Christophe BAL]

Christophe BAL added the comment:

I don't agree with you. I prefer to add new functionalities to the paths I
use. This is the power of OOP. It is easier and cleaner to use
*mypath.common_with(otherpath)*  than  *common_with(**mypath, **other path)*
.

Python is highly OOP, so you can't say *don't use subclassing in your
case*. As a user, I should have the possibility to use the method I want.

Another example is the use of  *onepath - anotherpath*  instead of
*onepath.relative_to(**another path)* . That's the power of the magic
method to add this kind of feature.

*Christophe BAL*
*Enseignant de mathématiques en Lycée **et développeur Python amateur*
*---*
*French math teacher in a Lycée **and **Python **amateur developer*

2015-05-06 20:21 GMT+02:00 Paul Moore rep...@bugs.python.org:


 Paul Moore added the comment:

 For that type of function, I'd suggest you use a standalone function
 rather than subclassing and methods or operator overloading. You don't gain
 enough to be worth the complexity of having to subclass path objects. And
 duck typing means that your function works for any subclass of (Pure)Path
 without change.

 --

 ___
 Python tracker rep...@bugs.python.org
 http://bugs.python.org/issue24132
 ___


--

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

[issue24132] Direct sub-classing of pathlib.Path

[Christophe BAL]

Christophe BAL added the comment:

OK.
I will try to find a way to achieve an easier and cleaner way to sub class
pathlib.Path and co.

What is the good way to propose a patch ?

*Christophe BAL*
*Enseignant de mathématiques en Lycée **et développeur Python amateur*
*---*
*French math teacher in a Lycée **and **Python **amateur developer*

2015-05-06 21:09 GMT+02:00 Paul Moore rep...@bugs.python.org:


 Paul Moore added the comment:

  Are you the author of path lib ?

 Nope, that's Antoine.

 --

 ___
 Python tracker rep...@bugs.python.org
 http://bugs.python.org/issue24132
 ___


--

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

[issue24132] Direct sub-classing of pathless.Path

[Christophe BAL]

New submission from Christophe BAL:

Hello.

I have noticed a problem with the following code.

from pathlib import Path

class PPath(Path):
def __init__(self, *args, **kwargs):
super().__init__(*args, **kwargs)

test = PPath(dir, test.txt)

This gives the following error message.

 
Traceback (most recent call last):
  File /Users/projetmbc/test.py, line 14, in module
test = PPath(dir, test.txt)
  File /anaconda/lib/python3.4/pathlib.py, line 907, in __new__
self = cls._from_parts(args, init=False)
  File /anaconda/lib/python3.4/pathlib.py, line 589, in _from_parts
drv, root, parts = self._parse_args(args)
  File /anaconda/lib/python3.4/pathlib.py, line 582, in _parse_args
return cls._flavour.parse_parts(parts)
AttributeError: type object 'PPath' has no attribute '_flavour'

This breaks the sub-classing from Python point of view.

There is an ugly hack to sub-class Path but it's a bit unpythonic.

--
messages: 242643
nosy: projetmbc
priority: normal
severity: normal
status: open
title: Direct sub-classing of pathless.Path
type: behavior
versions: Python 3.4

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

[issue24108] fnmatch.translate('*.txt') fails

[Christophe BAL]

Christophe BAL added the comment:

Ok.

But in that case, the official documentation should be updated because it
saids that string regex is  *'.*\\.txt\\Z(?ms)'*  and not  *'.*\\.txt$'*.

On the other hand, using this writing seems a bit strange. The 2nd one
should do the job.

*Christophe BAL*
*Enseignant de mathématiques en Lycée **et développeur Python amateur*
*---*
*French math teacher in a Lycée **and **Python **amateur developer*

2015-05-01 21:42 GMT+02:00 Merlijn van Deen rep...@bugs.python.org:


 Merlijn van Deen added the comment:

 As far as I can see, the regex is correct:

 \Z
 Matches only at the end of the string.

 (?iLmsux)
 The group matches the empty string; the letters set the corresponding
 flags: (...)
   - re.M (multi-line),
   - re.S (dot matches all)

 See https://docs.python.org/3.4/library/re.html

 Do you have an example where the regex does not match a file it should
 match (or matches a file it shouldn't)?

 --
 nosy: +valhallasw

 ___
 Python tracker rep...@bugs.python.org
 http://bugs.python.org/issue24108
 ___


--

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

[issue24108] fnmatch.translate('*.txt') fails

[Christophe BAL]

New submission from Christophe BAL:

Hello.

I find the following bug on Python 3.4.

 import fnmatch, re
 regex = fnmatch.translate('*.txt')
 regex
'.*\\.txt\\Z(?ms)'

The string regex should be '.*\\.txt$'.

--
components: asyncio
messages: 242346
nosy: gvanrossum, haypo, projetmbc, yselivanov
priority: normal
severity: normal
status: open
title: fnmatch.translate('*.txt') fails
versions: Python 3.4

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

[issue24108] fnmatch.translate('*.txt') fails

[Christophe BAL]

Christophe BAL added the comment:

Oups, sorry I want to say that you are totally RIGHT, and I am definitely
WRONG. :-)

--

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

[issue24108] fnmatch.translate('*.txt') fails

[Christophe BAL]

Christophe BAL added the comment:

You're totally wrong and I am wrong.

There is still the tiny problem of the documentation.

Thanks for all.

*Christophe BAL*
*Enseignant de mathématiques en Lycée **et développeur Python amateur*
*---*
*French math teacher in a Lycée **and **Python **amateur developer*

2015-05-01 22:16 GMT+02:00 Merlijn van Deen rep...@bugs.python.org:


 Merlijn van Deen added the comment:

 They are subtly different; the new regex also matches filenames with
 newlines, the old one doesn't (see Issue #6665 [1]).

 Patch (although crazily minor) attached. With some fuzz, it applies on
 everything from 2.6..default.

 [1] https://bugs.python.org/issue6665

 --
 assignee:  - docs@python
 components: +Documentation -asyncio
 keywords: +patch
 nosy: +docs@python
 Added file: http://bugs.python.org/file39261/default.diff

 ___
 Python tracker rep...@bugs.python.org
 http://bugs.python.org/issue24108
 ___


--

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

WSME -- Web Services Made Easy -- 0.6.4

[Christophe de Vienne]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

WSME -- Web Services Made Easy -- 0.6.4

   Web Service Made Easy (WSME) simplify the writing of REST web services
   by providing simple yet powerful typing which removes the need to
   directly manipulate the request and the response objects.

   WSME can work standalone or on top of your favorite python web
   (micro)framework, so you can use both your preferred way of routing
   your REST requests and most of the features of WSME that rely on the
   typing system like:
 * Alternate protocols, including ones supporting batch-calls
 * Easy documentation through a [1]Sphinx extension

What's New In This Release?

0.6.4 (2014-11-20)
--

- Include tests in the source distribution

0.6.3 (2014-11-19)
--

- Disable universal wheels

0.6.2 (2014-11-18)
--

* Flask adapter complex types now supports flask.ext.restful
* Allow disabling complex types auto-register
* Documentation edits
* Various documentation build fixes
* Fix passing Dict and Array based UserType as params

Documentation

   [2]Documentation for WSME is hosted on [3]readthedocs.org

References

   1. http://sphinx-doc.org/
   2. http://http://wsme.readthedocs.org/en/latest/
   3. http://readthedocs.org/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUedbWAAoJEFATnylB+5mRtl0H/AkUQAUcz58uAt+LIJbIFsnK
vZTjnCPm4/pAtEMLZw/8ZOlYdpBRvKFJEMoFRwJ0lDvvsDP1cK+VjQsZbncnliDI
0W3rDaHqFpCk12RHzaglOLP8VR7BzLVAqfqY2BtVBJ1yaThBxQw0xHXVy/ZX/xaW
n84JaScfVMaS06Baa7iaTZc0ED5v1Hf2iCv3xD5jpswvVp9Rx1c65SLwZjm3XqFn
nDBumn1W04Pwzp5mqW31ZOKKVzD4HDgB8CJS7Bql3Tahq36pvHMW3Axwlk3nVNEr
1mh3gsQFGxB/bkR//HApuuT7wQDzB8p8waL1DBiugVTxL9nGKcqh6xlsySnPn1c=
=vns4
-END PGP SIGNATURE-
-- 
https://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

[issue21081] missing vietnamese codec TCVN 5712:1993 in Python

[Jean Christophe André]

Changes by Jean Christophe André pyt...@andrele.org:


Added file: http://bugs.python.org/file37054/TCVN5712-1.TXT

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

[issue21081] missing vietnamese codec TCVN 5712:1993 in Python

[Jean Christophe André]

Changes by Jean Christophe André pyt...@andrele.org:


Added file: http://bugs.python.org/file37055/TCVN5712-2.TXT

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

[issue21081] missing vietnamese codec TCVN 5712:1993 in Python

[Jean Christophe André]

Changes by Jean Christophe André pyt...@andrele.org:


Added file: http://bugs.python.org/file37056/TCVN5712-3.TXT

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

[issue21081] missing vietnamese codec TCVN 5712:1993 in Python

[Jean Christophe André]

Jean Christophe André added the comment:

I failed to find anything about TCVN 5712:1999 except the official announcement 
of it superseding TCVN 5712:1993 on TCVN's website. I also was not able to find 
any material using TCVN 5712:1999. My guess is that TCVN 6909:2001 having been 
released only 2 years after, TCVN 5712:1999 probably had no time to get in real 
use.

Anyway, TCVN 5712:1993 is the real one, the one having been in used for almost 
2 decades. So this is why I provided codec tables for this one.

There is 3 flavors of it. The most used one for documents is the third one 
(TCVN 5712:1993 VN3). It is used with the so called “ABC fonts” which are of 
common knowledge in Vietnam. But the first one may be of use in databases. I 
never got access to real (large) Vietnamese databases so I can't confirm it for 
sure. I still provided the 3 flavors, just in case.

Still, since VN3 is a subset of VN2, which itself is a subset of VN1, you may 
choose to only include the first one, TCVN 5712:1993 VN1, I leave this up to 
you. FYI, GNU Recode and Glibc Iconv currently implement tcvn as VN1. (but 
the Epson printer company implement VN3…)

--

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

[issue21081] missing vietnamese codec TCVN 5712:1993 in Python

[Jean Christophe André]

Jean Christophe André added the comment:

Marc-Andre, about “Please also provide a patch for the documentation”, could 
you please guide me on this?

I can write some documentation, but I simply don't know in what form you expect 
it. Could you point me to some examples please?

--

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

[issue21081] missing vietnamese codec TCVN 5712:1993 in Python

[Jean Christophe André]

Changes by Jean Christophe André pyt...@andrele.org:


Removed file: http://bugs.python.org/file34644/vntime_tcvn.py

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

[issue22679] Add encodings of supported in glibc locales

[Jean Christophe André]

Changes by Jean Christophe André pyt...@andrele.org:


--
nosy: +progfou

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

[issue21081] missing vietnamese codec TCVN 5712:1993 in Python

[Jean Christophe André]

Jean Christophe André added the comment:

A note to inform about my progress. (I had a long period without free time at 
hand)

While seeking (again) official documents on the topic, I mainly found a lot of 
non-official ones, but some are notorious enough to use them as references.

I am now in the process of creating the requested patch. I am currently 
studying the proper way to do it. I expect to get it ready this weekend, in the 
hope to have it accepted for Python 3.5.

--

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

[issue21081] missing vietnamese codec TCVN 5712:1993 in Python

[Jean Christophe André]

Jean Christophe André added the comment:

 * Please provide some background information how widely the encoding is used. 
 I get less than 1000 hits in Google when looking for TCVN 5712:1993.

Here is the background for the need for this encoding.

The recent laws[0] in Vietnam have set TCVN 6909:2001 (Unicode based) as the 
standard encoding everybody should use. Still, there was more than 30 old 
Vietnamese encodings that were used for tenths of years before that, with some 
of them being still used (it takes times for people to accept the change and 
for technicians to do what's required to change technology). Among them, TCVN 
5712:1993 was (is) mostly used in the North of Vietnam and VNI (a private 
company encoding) in the South of Vietnam.

Worse than that, these old encodings use the C0 bank to store some Vietnamese 
letters (especially the 'ư', one of the most used in this language), which has 
the very unpleasant consequence to let some software (like 
OpenOffice/LibreOffice) being unable to render the texts correctly, even when 
using the correct fonts. Since this was a showstopper for Free Software 
adoption in Vietnam, I decided at that time to create a tool[1][2] to help in 
converting from these old encodings to Unicode. The project was then endorsed 
by the Ministry of Sciences and Technology of Vietnam, which asked me to make 
further developments[3].

Even if these old encodings are, hopefully, not the widest used in Vietnam now, 
there are still tons/plenty of old documents (sorry, I can't be more precise on 
the volume of administrative or private documents) that need to be 
read/modified or, best, converted to Unicode; and here is where the encodings 
are needed. Now every time some Vietnamese people (and Laotian people, I'll 
come back on this in another bug report) want to use OpenOffice/LibreOffice and 
still be able to open their old documents, they have to install this Python 
extension for this.

I foresee there will be not only plain documents to convert but also databases 
and other kind of data storage. And here is where Python has a great occasion 
to become the tool of choice.

[0] 
http://thuvienphapluat.vn/archive/Quyet-dinh-72-2002-QD-TTg-thong-nhat-dung-bo-ma-ky-tu-chu-Viet-TCVN-6909-2001-trao-doi-thong-tin-dien-tu-giua-to-chuc-dang-nha-nuoc-vb49528.aspx
[1] http://wiki.hanoilug.org/projects:ovniconv
[2] http://extensions.services.openoffice.org/project/ovniconv
[3] http://extensions.services.openoffice.org/en/project/b2uconverter


 Now, the encoding was a standard in Vietnam, but it has been updated in 1999 
 to TCVN 5712:1999.

I have to admit I missed this one. It may explain the differences I saw when I 
reversed engineered the TCVN encoding through the study the documents 
Vietnamese users provided to me. I will check this one and come back with more 
details.

 There's also an encoding called VSCII.

VSCII is the same as TCVN 5712:1993.

This page contains interesting information about these encodings: 
http://www.informatik.uni-leipzig.de/~duc/software/misc/tcvn.txt


 * In the file you write kind of TCVN 5712:1993 VN3 with CP1252 additions. 
 This won't work, since we can only accept codecs which are based on set 
 standards.

I can understand that and I'll do my best to check if it's really based on one 
of the TCVN standards, be it 5712:1993 or 5712:1999. Still, after years of 
usage, I know perfectly that it's exactly the encoding we need (for the North 
part of Vietnam at least).


 It would be better to provide a link to an official Unicode character set 
 mapping table and then use the gencodec.py script on this table.

I saw a reference to this processing tool in the Python provided encodings and 
tried to find a Unicode mapping table at the Unicode website but failed up to 
now. I'll try harder.


 * For Vietnamese, Python already provides cp1258 - how much is this encoding 
 used in comparison to e.g. TCVN 5712:1993 ?

To be efficient at typing Vietnamese, you need a keyboard input software 
(Vietkey and Unikey being the most used). Microsoft tried to create dedicated 
Vietnamese encoding (cp1258) and keyboard, but I never saw or heard about its 
adoption at any place. Knowing the way Vietnamese users use their computer, I 
would say it probably has never been in real use.


 * Vietnamese encodings: 
 http://www.panl10n.net/english/outputs/Survey/Vietnamese.pdf

In this sentence you can see the most used old encodings in Vietnam: “On the 
Linux platform, fonts based on Unicode [6], TCVN, VNI and VPS [7] encodings can 
be adequately used to input Vietnamese text.”

This is not only the most used on Linux (in fact, on Linux we have to use 
Unicode, mostly because of the problem I explained before) but also on Windows. 
I don't know the situation for Mac OS or other OS though.

My goal is to add these encodings into Python, to help Vietnam make its steps 
into Unicode.


 * East Asian encodings: http://www.unicode.org/iuc/iuc15/tb1/slides.pdf

[issue21081] missing vietnamese codec TCVN 5712:1993 in Python

[Jean Christophe André]

Jean Christophe André added the comment:

I will prepare the official encoding map(s) based on the standard(s).

I'll also have to check which encoding correspond to my current encoding map, 
since this is the one useful in real life.

 Please also provide a patch for the documentation

I currently have no idea how to do this. Could you point me to a documentation 
sample or template please?

 and sign the Python contrib form:
 https://www.python.org/psf/contrib/contrib-form/

I did it yesterday. The form tells it can take days to be integrated, but I did 
receive the signed document as a confirmation.

Thanks for your concern, J.C.

--

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

[issue21081] missing vietnamese codec TCVN 5712:1993 in Python

[Jean Christophe André]

New submission from Jean Christophe André:

In Python version 2.x and at least 3.2 there no Vietnamese encoding support for 
TCVN 5712:1993.

This encoding is currently largely used in Vietnam and I think it would be 
usefull to add it to the python core encodings.

I already wrote some codec code, based on the codecs already available, that I 
successfully used in real life situation.

I would like to give it as a contribution to Python.

--
components: Unicode
files: vntime_tcvn.py
messages: 215012
nosy: ezio.melotti, haypo, progfou
priority: normal
severity: normal
status: open
title: missing vietnamese codec TCVN 5712:1993 in Python
type: enhancement
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file34644/vntime_tcvn.py

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

WSME 0.5b5 released

[Christophe de Vienne]

About WSME
--

Web Service Made Easy (WSME) simplify the writing of REST web services
by providing simple yet powerful typing which removes the need to
directly manipulate the request and the response objects.

WSME can work standalone or on top of your favorite python web
(micro)framework, so you can use both your preferred way of routing your
REST requests and most of the features of WSME that rely on the typing
system like:

*   Alternate protocols, including ones supporting batch-calls

*   Easy documentation through a Sphinx extension


Changes
---

0.5b5 (2013-09-16)
--

More packaging fixes.

0.5b4 (2013-09-11)
--

Fixes some release-related files for the stackforge release process.
No user-facing bug fixes or features over what 0.5b3 provides.

0.5b3 (2013-09-04)
--

The project moved to stackforge. Mind the new URLs for the repository,
bugreport etc (see the documentation).

*   Allow non-default status code return with the pecan adapter
(Angus Salked).

*   Fix returning objects with object attributes set to None on
rest-json  ExtDirect.

*   Allow error details to be set on the Response object
(experimental !).

*   Fix: Content-Type header is not set anymore when the return type is
None on the pecan adapter.

*   Support unicode message in ClientSideError (Mehdi Abaakouk).

*   Use pbr instead of d2to1 (Julien Danjou).

*   Python 3.3 support (Julien Danjou).

*   Pecan adapter: returned status can now be set on exceptions (Vitaly
Kostenko).

*   TG adapters: returned status can be set on exceptions (Ryan
Petrello).

*   six = 1.4.0 support (Julien Danjou).

*   Require ordereddict from pypi for python  2.6 (Ryan Petrello).

*   Make the code PEP8 compliant (Ryan Petrello).

Documentation
-

http://pythonhosted.org/WSME/

Download


http://pypi.python.org/pypi/WSME/


Cheers,

Christophe de Vienne
-- 
https://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

WSME 0.5b2 released

[Christophe de Vienne]

About WSME
--

Web Service Made Easy (WSME) simplify the writing of REST web services 
by providing simple yet powerful typing which removes the need to 
directly manipulate the request and the response objects.


WSME can work standalone or on top of your favorite python web 
(micro)framework, so you can use both your preferred way of routing your 
REST requests and most of the features of WSME that rely on the typing 
system like:


*   Alternate protocols, including ones supporting batch-calls

*   Easy documentation through a Sphinx extension


Main Changes


*   Changed the way datas of complex types are stored. In previous
versions, an attribute was added to the type for each attribute,
its name being the attribute name prefixed with '_'.

Starting with this version, a single attribute _wsme_dataholder is
added to the instance.

The motivation behind this change is to avoid adding too many
attributes to the object.

*   Add a special type 'HostRequest' that allow a function to ask for
the host framework request object in its arguments.

*   Pecan adapter: Debug mode (which returns the exception tracebacks
to the client) can be enabled by the pecan application
configuration.

*   New adapter: wsmeext.flask, for the Flask framework.

*   Various bug fixes.


Documentation
-

http://pythonhosted.org/WSME/

Download


http://pypi.python.org/pypi/WSME/


Cheers,

Christophe de Vienne
--
http://mail.python.org/mailman/listinfo/python-announce-list

   Support the Python Software Foundation:
   http://www.python.org/psf/donations/

WSME 0.5b1 released

[Christophe de Vienne]

About WSME
--

Web Service Made Easy (WSME) simplify the writing of REST web services 
by providing simple yet powerful typing which removes the need to 
directly manipulate the request and the response objects.


WSME can work standalone or on top of your favorite python web 
(micro)framework, so you can use both your prefered way of routing your 
REST requests and most of the features of WSME that rely on the typing 
system like:


*   Alternate protocols, including ones supporting batch-calls

*   Easy documentation through a Sphinx extension


Main Changes


*   Introduce a new kind of adapters that rely on the framework routing.
Adapters are provided for Pecan, TurboGears and cornice.

*   The default rest ``@expose`` decorator does not wrap the decorated
function anymore. If needed to expose a same function several
times, a parameter ``multiple_expose=True`` has been introduced.

*   Remove the wsme.release module

*   Adapted the wsme.sphinxext module to work with the function exposed
by the ``wsme.pecan`` adapter.

*   Allow promotion of ``int`` to ``float`` on float attributes
(Doug Hellman)

*   Add a ``samples_slot`` option to the ``.. autotype`` directive to
choose where the data samples whould be inserted (Doug Hellman).

*   Add ``sample()`` to ArrayType and DictType (Doug Hellman).

*   New syntax for object arrays as GET parameters, without brackets.
Ex:
``?o.f1=ao.f1=bo.f2=co.f2=d`` is an array of two objects:
[{'f1': 'a', 'f2': 'c']}, {'f1': 'b', 'f2': 'd'}].

*   @signature (and its @wsexpose frontends) has a new parameter:
``ignore_extra_args``.

*   Fix boolean as input type support in the soap implementation (Craig
McDaniel).

*   Fix empty/nil strings distinction in soap (Craig McDaniel).

*   Improved unittests code coverage.

*   Ported the soap implementation to python 3.

*   Moved non-core features (adapters, sphinx extension) to the
``wsmeext`` module.

*   Change the GET parameter name for passing the request body as a
parameter is now from 'body' to '__body__'

*   The soap, extdirect and sqlalchemy packages have been merged into
the main package.

*   Changed the documentation theme to Cloud.


Documentation
-

http://packages.python.org/WSME/


Download


http://pypi.python.org/pypi/WSME/


Cheers,

Christophe de Vienne
--
http://mail.python.org/mailman/listinfo/python-announce-list

   Support the Python Software Foundation:
   http://www.python.org/psf/donations/

WSME-Soap 0.4.1 released

[Christophe de Vienne]

WSME-Soap 0.4.1 was released today.

It is a bugfix release.

Changes
---

* Fix date/time and binary input types handling

Download


http://pypi.python.org/pypi/WSME-Soap/




Cheers,

Christophe de Vienne

--
http://mail.python.org/mailman/listinfo/python-announce-list

   Support the Python Software Foundation:
   http://www.python.org/psf/donations/

WSME 0.4 released

[Christophe de Vienne]

About WSME
--

WSME (Web Service Made Easy) is a very easy way to implement webservices
in your python web application (or standalone).

Main Changes


*   Automatically converts unicode strings to/from ascii bytes.

*   Use d2to1 to simplify setup.py.

*   Implements the SPORE specification.

*   Fixed a few things in the documentation


Documentation
-

http://packages.python.org/WSME/


Download


http://pypi.python.org/pypi/WSME/

http://pypi.python.org/pypi/WSME-Soap/
http://pypi.python.org/pypi/WSME-ExtDirect/
http://pypi.python.org/pypi/WSME-SQLAlchemy/


Cheers,

Christophe de Vienne
--
http://mail.python.org/mailman/listinfo/python-announce-list

   Support the Python Software Foundation:
   http://www.python.org/psf/donations/

deque and thread-safety

[Christophe Vandeplas]

Hello,

I have a question about deque and thread-safety.

My application has multiple threads running concurrently and doing the
same action (downloading pages)
To know what has already been downloaded I created the variable:
  seen = deque('', 1000)   (keeps list of max 1000 urls in memory)

In one place of the code I do:  seen.append(url)

And another place:
def seenPage()
  if url in seen:
return True
  return False

From the documentation I understand that deques are thread-safe:
 Deques are a generalization of stacks and queues (the name is pronounced 
 “deck”
 and is short for “double-ended queue”). Deques support thread-safe, memory
 efficient appends and pops from either side of the deque with approximately 
 the
 same O(1) performance in either direction.

It seems that appending to deques is indeed thread-safe, but not
iterating over them.
I've seen a similar, but different, situation here:
http://comments.gmane.org/gmane.comp.python.devel/85487

Forgetting the above url, and considering my situation this behavior
screws up the concept I need:
- Keeping a thread-safe collection of seen urls,
- Being able to check if something is in that collection
- No need to clean the collection to prevent the memory from filling up

So I know I could work around this problem by using a lock.
But then I don't only need to use the lock around the iterator, but
also around the append(), but that defeats the purpose of deque being
thread-safe.

In short, what's your advice:

1/ build a lock around the .append() and the iterator. Using the
already-existing lock in the deque. But HOW?

1/ simply build a lock around the .append() and the iterator.
Defeating the build-in thread-safety.

2/ use another collection that does what I need


Thanks for your expertise.

Christophe
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: deque and thread-safety

[Christophe Vandeplas]

Ok sorry for the mail,
I found the solution by using deque.count(url) that's available
starting from python 2.7


On Fri, Oct 12, 2012 at 2:40 PM, Christophe Vandeplas
christo...@vandeplas.com wrote:
 Hello,

 I have a question about deque and thread-safety.

 My application has multiple threads running concurrently and doing the
 same action (downloading pages)
 To know what has already been downloaded I created the variable:
   seen = deque('', 1000)   (keeps list of max 1000 urls in memory)

 In one place of the code I do:  seen.append(url)

 And another place:
 def seenPage()
   if url in seen:
 return True
   return False

 From the documentation I understand that deques are thread-safe:
 Deques are a generalization of stacks and queues (the name is pronounced 
 “deck”
 and is short for “double-ended queue”). Deques support thread-safe, memory
 efficient appends and pops from either side of the deque with approximately 
 the
 same O(1) performance in either direction.

 It seems that appending to deques is indeed thread-safe, but not
 iterating over them.
 I've seen a similar, but different, situation here:
 http://comments.gmane.org/gmane.comp.python.devel/85487

 Forgetting the above url, and considering my situation this behavior
 screws up the concept I need:
 - Keeping a thread-safe collection of seen urls,
 - Being able to check if something is in that collection
 - No need to clean the collection to prevent the memory from filling up

 So I know I could work around this problem by using a lock.
 But then I don't only need to use the lock around the iterator, but
 also around the append(), but that defeats the purpose of deque being
 thread-safe.

 In short, what's your advice:

 1/ build a lock around the .append() and the iterator. Using the
 already-existing lock in the deque. But HOW?

 1/ simply build a lock around the .append() and the iterator.
 Defeating the build-in thread-safety.

 2/ use another collection that does what I need


 Thanks for your expertise.

 Christophe
-- 
http://mail.python.org/mailman/listinfo/python-list

WSME 0.4b1 released

[Christophe de Vienne]

About WSME
--

WSME (Web Service Made Easy) is a very easy way to implement webservices
in your python web application (or standalone).

What's New ?


This release brings new features like a Base class for complex types, a
File type for transferring files, more restful rest protocols with the
use of the http method...

A new extension, WSME-SQLAlchemy, provides tools to build an api on top
of SQLAlchemy mapped classes.

The WSME-ExtDirect extension uses this extension to build almost
instantly ExtJS DirectStores and Model from SQLAlchemy mapped classes.

Main Changes


* Now supports Python 3.2 (except for wsme-soap).
* String types handling is clearer.
* New wsme.types.File type.
* Supports cross-referenced types.
* Various bugfixes.
* Tests code coverage is now over 95%.
* RESTful protocol can now use the http method.
* UserTypes can now be given a name that will be used in the
  documentation.
* Complex types can inherit wsme.types.Base. They will have a default
  constructor and be registered automatically.
* Removed the wsme.wsgi.adapt function if favor of wsme.WSRoot.wsgiapp()

Extensions changes
--

WSME-Soap
~

* Function names now starts with a lowercase letter.
* Fixed issues with arrays (issue #3).
* Fixed empty array handling.

WSME-SQLAlchemy
~~~

This new extension makes it easy to create webservices on top of a
SQLAlchemy set of mapped classes.

WSME-ExtDirect
~~

* Implements server-side DataStore
* Add Store and Model javascript definition auto-generation
* Add Store server-side based on SQLAlchemy mapped classes.


Documentation
-

http://packages.python.org/WSME/


Download


http://pypi.python.org/pypi/WSME/

http://pypi.python.org/pypi/WSME-Soap/
http://pypi.python.org/pypi/WSME-SQLAlchemy/
http://pypi.python.org/pypi/WSME-ExtDirect/



Cheers,

Christophe de Vienne
-- 
http://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

odt2sphinx 0.2.3 released

[Christophe de Vienne]

Hello,

odt2sphinx 0.2.3 is now available on pypi :

http://pypi.python.org/pypi/odt2sphinx/.

Odt2sphinx convert OpenDocument Text file(s) to one or several .rst
files suitable for Sphinx.

Changes
---

* Fix filename generation by replacing any non-alphanumeric
  character (issue #3).

* Fix handling of non-styled lists.


Regards,

Christophe de Vienne
-- 
http://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

[Christophe Guillon]

Christophe Guillon added the comment:

As a workaround for this missing feature,
the negative number matching regexp can be used for allowing arguments starting 
with '-' in arguments of option flags.

We basically do:
parser = argparse.ArgumentParser(...)
parser._negative_number_matcher = re.compile(r'^-.+$')

This allow cases such as @andersk:
$ a2x --asciidoc-opts --safe gitcli.txt
where '--safe' is an argument to '--asciidoc-opts'

As this behavioral change is quite simple, couldn't the requested feature be 
implemented like this with an optional setting to the ArgumentParser contructor?

--
nosy: +Christophe.Guillon

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9334
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

odt2sphinx 0.2.1 released

[Christophe de Vienne]

Hello,

odt2sphinx 0.2.1 is now available on pypi :

http://pypi.python.org/pypi/odt2sphinx/.

Odt2sphinx convert OpenDocument Text file(s) to one or several .rst
files suitable for Sphinx.

Changes
---

* Add support for numbered lists, hyperlinks, underlined text
  (translated to italic).
* Fix bold text support.


Regards,

Christophe de Vienne
--
http://mail.python.org/mailman/listinfo/python-announce-list

   Support the Python Software Foundation:
   http://www.python.org/psf/donations/

odt2sphinx 0.2 released

[Christophe de Vienne]

Hello,

odt2sphinx 0.2 is now available on pypi :

http://pypi.python.org/pypi/odt2sphinx/.

Odt2sphinx convert OpenDocument Text file(s) to one or several .rst
files suitable for Sphinx.

Changes
---

* Now supports python 3
* Explicitely added PIL as a dependency (issue #2).

Regards,

Christophe de Vienne
-- 
http://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

odt2sphinx 0.1.2 released

[Christophe de Vienne]

Hello,

odt2sphinx 0.1.2 is now available on pypi :
http://pypi.python.org/pypi/odt2sphinx/.

Odt2sphinx convert OpenDocument Text file(s) to one or several .rst
files suitable for Sphinx.

Changes
---

* Now handle external images (issue #1).
* Handle note, tip and warning styles in lists items. This allow to use
lists inside a note, a tip or a warning.
* Add Information to the styles mapping.

Regards

Christophe de Vienne
-- 
http://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

[issue14517] Recompilation of sources with Distutils

[Christophe Benoit]

Christophe Benoit cca.ben...@gmail.com added the comment:

2012/4/22 Éric Araujo rep...@bugs.python.org


 Éric Araujo mer...@netwok.org added the comment:

 Is it #5372?

 --

 ___
 Python tracker rep...@bugs.python.org
 http://bugs.python.org/issue14517
 ___


Yes, I think so. The problem is :
For modules with a lot of .c, recompiling everything can take a very long
time...
In fact, it becomes very cumbersome for me and my co-workers...
Is there a way to make the previous check on timestamps optional?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14517
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

WSME 0.3 released

[Christophe de Vienne]

About WSME
--

WSME (Web Service Made Easy) is a very easy way to implement webservices
in your python web application (or standalone).

Main Changes


* Introduce a sphinx extension to easily document your api.

More details on http://packages.python.org/WSME/changes.html.


Documentation
-

http://packages.python.org/WSME/


Download


http://pypi.python.org/pypi/WSME/

http://pypi.python.org/pypi/WSME-Soap/
http://pypi.python.org/pypi/WSME-ExtDirect/



Cheers,

Christophe de Vienne
--
http://mail.python.org/mailman/listinfo/python-announce-list

   Support the Python Software Foundation:
   http://www.python.org/psf/donations/

[issue14517] Recompilation of sources with Distutils

[Christophe Benoit]

New submission from Christophe Benoit cca.ben...@gmail.com:

When using distutils to build a C-extension, I have noticed that 
my C-sources were recompiled as soon as one source file has been touched;
from python 2.6. This was not the case with previous python versions.

--
assignee: eric.araujo
components: Distutils
messages: 157659
nosy: cbenoit, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Recompilation of sources with Distutils
type: behavior
versions: Python 2.7

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14517
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

WSME 0.3b2 released

[Christophe de Vienne]

About WSME
--

WSME (Web Service Made Easy) is a very easy way to implement webservices
in your python web application (or standalone).

Main Changes


* wsattr now takes a 'default' parameter that will be returned
  instead of 'Unset' if no value has been set.

* Bug fixes

More details on http://packages.python.org/WSME/changes.html.


Documentation
-

http://packages.python.org/WSME/


Download


http://pypi.python.org/pypi/WSME/

http://pypi.python.org/pypi/WSME-Soap/
http://pypi.python.org/pypi/WSME-ExtDirect/



Cheers,

Christophe de Vienne
-- 
http://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

[issue13966] Add disable_interspersed_args() to argparse.ArgumentParser

[Christophe Kalt]

Christophe Kalt k...@taranis.org added the comment:

nice, thank you!

--
nosy: +kalt

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13966
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13922] argparse handling multiple -- in args improperly

[Christophe Kalt]

Christophe Kalt k...@taranis.org added the comment:

Hah.. was just about to report this.  I'm in the midst of converting a bunch of 
scripts from optparse to argparse, and this is one of the problems I'm hitting.

--
nosy: +kalt

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13922
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

WSME 0.3b1

[Christophe de Vienne]

About WSME
--

WSME (Web Service Made Easy) is a very easy way to implement webservices
in your python web application (or standalone).

Main Changes


* Per-call database transaction handling.

* Attributes of complex types can now have a different name in the
  public api and in the implementation.

* Complex arguments can now be sent as GET/POST params in the rest
  protocols.

* The restjson protocol do not nest the results in an object anymore.

* Improved the documentation

More details on http://packages.python.org/WSME/changes.html.


Documentation
-

http://packages.python.org/WSME/


Download


http://pypi.python.org/pypi/WSME/

http://pypi.python.org/pypi/WSME-Soap/
http://pypi.python.org/pypi/WSME-ExtDirect/



Cheers,

Christophe de Vienne
-- 
http://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

WSME 0.2.0 released

[Christophe de Vienne]

About WSME
--

WSME (Web Service Made Easy) is a very easy way to implement webservices
in your python web application (or standalone).

Main Changes


*   Added batch-calls abilities.

*   Introduce a :class:`UnsetType` and a :data:`Unset` constant
so that non-mandatory attributes can remain unset (which is
different from null).

*   Add support for user types.

*   Add an Enum type (which is a user type).

*   Various fixes

More details on http://packages.python.org/WSME/changes.html.


Documentation
-

http://packages.python.org/WSME/


Download


http://pypi.python.org/pypi/WSME/

http://pypi.python.org/pypi/WSME-Soap/
http://pypi.python.org/pypi/WSME-ExtDirect/



Cheers,

Christophe de Vienne
--
http://mail.python.org/mailman/listinfo/python-announce-list

   Support the Python Software Foundation:
   http://www.python.org/psf/donations/

WSME 0.1.1 released

[Christophe de Vienne]

About WSME
--

WSME (Web Service Made Easy) is a very easy way to implement webservices
in your python web application (or standalone).

Changes
---

* Changed the internal API by introducing a CallContext object. It
  makes it easier to implement some protocols that have a transaction
  or call id that has to be returned. It will also make it possible to
  implement batch-calls in a later version.

* More test coverage.

* Various fixes (see also http://packages.python.org/WSME/changes.html)

Documentation
-

http://packages.python.org/WSME/


Download


http://pypi.python.org/pypi/WSME/

http://pypi.python.org/pypi/WSME-Soap/
http://pypi.python.org/pypi/WSME-ExtDirect/



Cheers,

Christophe de Vienne
-- 
http://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

WSME 0.1.0 released

[Christophe de Vienne]

About WSME
--

WSME (Web Service Made Easy) is a very easy way to implement webservices
in your python web application (or standalone).


Changes
---

* Move the soap protocol implementation in a separate lib, WSME-Soap
* Introduce a new protocol ExtDirect in the WSME-ExtDirect lib.

See also http://packages.python.org/WSME/changes.html


Documentation
-

http://packages.python.org/WSME/


Download


http://pypi.python.org/pypi/WSME/

http://pypi.python.org/pypi/WSME-Soap/
http://pypi.python.org/pypi/WSME-ExtDirect/



Cheers,

Christophe de Vienne
-- 
http://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

WSME 0.1.0a4 released

[Christophe de Vienne]

Hello,

I am happy to announce the release of WSME-0.1.0a4.


About WSME
--

WSME (Web Service Made Easy) is a very easy way to implement webservices
in your python web application (or standalone).


Changes
---

* Protocols can be added via entry_points
* Made the framework adapters easier to use

See also http://packages.python.org/WSME/changes.html


Documentation
-

http://packages.python.org/WSME/


Download


http://pypi.python.org/pypi/WSME



Cheers,

Christophe de Vienne
--
http://mail.python.org/mailman/listinfo/python-announce-list

   Support the Python Software Foundation:
   http://www.python.org/psf/donations/

WSME 0.1.0a3 released

[Christophe de Vienne]

Hello,

I am happy to announce the release of WSME-0.1.0a3.

About WSME
--

WSME (Web Service Made Easy) is a very easy way to implement webservices
in your python web application (or standalone).

* Very simple API.
* Supports user defined complex types.
* Multi-protocol : REST+Json, REST+XML, SOAP, and more to come.
* Extensible : easy to add more protocols or more base types.
* Framework independance : adapters are provided to easily integrate
your API in any web framework, for example a wsgi container, turbogears,
and more to come.
* Very few runtime dependencies: webob, simplegeneric (+ Genshi if you
use SOAP).
* Integration in Sphinx for making clean documentation with
sphinxcontrib-wsme (not released yet).

Download


http://pypi.python.org/pypi/WSME

Documentation
-

http://packages.python.org/WSME/changes.html


Cheers,

Christophe de Vienne
-- 
http://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

Re: Floating point multiplication in python

[Christophe Chong]

And then we learned in class what happens when you're calculating 0.1 with
different precision in the industry.

http://www.ima.umn.edu/~arnold/disasters/patriot.html

Beware.

On Tue, Sep 6, 2011 at 3:14 AM, Thomas Rachel 
nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa...@spamschutz.glglgl.de wrote:

 Am 06.09.2011 07:57 schrieb xyz:

 hi all:

 As we know ,  1.1 * 1.1 is 1.21 .
 But in python ,I got following :

  1.1 * 1.1

 1.2102

 why python get wrong result? Who can tell me  where's the
 0.0002 from?


 1.1 does not fit in a binary floating point number. It is approximated - in
 binary! - as 1.000110011001100110011 ... (periodically).

 Note that, while in the decimal system we normally use, only numbers which
 have other components in the denominator than 2 or 5 are periodically, in
 the binary systems only components with 2 are allowed in order not to be
 periodically.

 Example: 3.453 is not periodically, because it is 3453/100 and 100 has only
 the factors 2 and 5, each twice.

 1/3 = .333... is periodically, because it has the factor 3. The same
 applies to 1/6, which has 2 and 3 as factors. The latter destroys the
 non-periodical behaviour.

 As said, in the dual system, only the 2 is allowed.

 .5 (10) = 2** -1 = .1 (2).
 .25 (10) = 2 ** -2 = .01 (2).
 .75 (10) = their sum = .11 (2).

 But .1 (1/10) is more complicated, -2 would be as well.

 As the IEEE floating point representation is limited, there is a slight
 error value which makes the stored value differ from the intended one.

 Look here:



  x=(1,0,0,0,1,1,0,0,1,1,0,0,1,**1,0,0,1,1,0,0,1,1,0,0,1,1,0,0,**
 1,1,0,0,1,1,0,0,1,1,0,0,1,1,0,**0,1,1,0,0,1,1,0,0,1,1,0,0,1,1)
 a=0
 for n,i in enumerate(x): a += i*2**-n; print a, a-1.1, i*2**-n, a-olda

 ...
 1 -0.1 1 1
 1.0 -0.1 0.0 0.0
 1.0 -0.1 0.0 0.0
 1.0 -0.1 0.0 0.0
 1.0625 -0.0375 0.0625 0.0625
 1.09375 -0.00625 0.03125 0.03125
 1.09375 -0.00625 0.0 0.0
 1.09375 -0.00625 0.0 0.0
 1.09765625 -0.00234375 0.00390625 0.00390625
 1.099609375 -0.000390625 0.001953125 0.001953125
 1.099609375 -0.000390625 0.0 0.0
 1.099609375 -0.000390625 0.0 0.0
 1.09985351562 -0.000146484375 0.000244140625 0.000244140625
 1.09997558594 -2.44140625001e-05 0.0001220703125 0.0001220703125
 1.09997558594 -2.44140625001e-05 0.0 0.0
 1.09997558594 -2.44140625001e-05 0.0 0.0
 1.0084473 -9.15527343759e-06 1.52587890625e-05 1.52587890625e-05
 1.0847412 -1.52587890634e-06 7.62939453125e-06 7.62939453125e-06
 1.0847412 -1.52587890634e-06 0.0 0.0
 1.0847412 -1.52587890634e-06 0.0 0.0
 1.094278 -5.72204589933e-07 9.53674316406e-07 9.53674316406e-07
 1.0990463 -9.53674317294e-08 4.76837158203e-07 4.76837158203e-07
 1.0990463 -9.53674317294e-08 0.0 0.0
 1.0990463 -9.53674317294e-08 0.0 0.0
 1.0996424 -3.57627869541e-08 5.96046447754e-08 5.96046447754e-08
 1.0999404 -5.96046456636e-09 2.98023223877e-08 2.98023223877e-08
 1.0999404 -5.96046456636e-09 0.0 0.0
 1.0999404 -5.96046456636e-09 0.0 0.0
 1.0999776 -2.23517426789e-09 3.72529029846e-09 3.72529029846e-09
 1.063 -3.72529118664e-10 1.86264514923e-09 1.86264514923e-09
 1.063 -3.72529118664e-10 0.0 0.0
 1.063 -3.72529118664e-10 0.0 0.0
 1.086 -1.3969847501e-10 2.32830643654e-10 2.32830643654e-10
 1.098 -2.32831531832e-11 1.16415321827e-10 1.16415321827e-10
 1.098 -2.32831531832e-11 0.0 0.0
 1.098 -2.32831531832e-11 0.0 0.0
 1.099 -8.73123795486e-12 1.45519152284e-11 1.45519152284e-11
 1.1 -1.45528034068e-12 7.27595761418e-12 7.27595761418e-12
 1.1 -1.45528034068e-12 0.0 0.0
 1.1 -1.45528034068e-12 0.0 0.0
 1.1 -5.45785638906e-13 9.09494701773e-13 9.09494701773e-13
 1.1 -9.10382880193e-14 4.54747350886e-13 4.54747350886e-13
 1.1 -9.10382880193e-14 0.0 0.0
 1.1 -9.10382880193e-14 0.0 0.0
 1.1 -3.41948691585e-14 5.68434188608e-14 5.68434188608e-14
 1.1 -5.77315972805e-15 2.84217094304e-14 2.84217094304e-14
 1.1 -5.77315972805e-15 0.0 0.0
 1.1 -5.77315972805e-15 0.0 0.0
 1.1 -2.22044604925e-15 3.5527136788e-15 3.5527136788e-15
 1.1 -4.4408920985e-16 1.7763568394e-15 1.7763568394e-15
 1.1 -4.4408920985e-16 0.0 0.0
 1.1 -4.4408920985e-16 0.0 0.0
 1.1 -2.22044604925e-16 2.22044604925e-16 2.22044604925e-16
 1.1 0.0 1.11022302463e-16 2.22044604925e-16
 1.1 0.0 0.0 0.0
 1.1 0.0 0.0 0.0
 1.1 0.0 1.38777878078e-17 0.0
 1.1 0.0 6.93889390391e-18 0.0

 So here we have reached the point where the maximum precision is reached -
 a doesn't change anymore, although it should. The error is about 1E-16.

 Now if you multiply two values with an error, the error also propagates
 into the result - PLUs the result can have its own error source - in the
 same order of magnitude.

 (a+e) * (a+e) = a*a + 2*a*e + e*e. So your new error term is 2*a*e + e*e or
 (2*a + e) * e.

 --
 http://mail.python.org/**mailman/listinfo/python-listhttp://mail.python.org/mailman/listinfo/python-list




-- 
Christophe Chong
Department of Economics
Stanford University
-- 
http

Re: Ten rules to becoming a Python community member.

[Christophe Chong]

I can't tell which comments are sarcastic

On Aug 14, 2011, at 18:35, rantingrick rantingr...@gmail.com wrote:

 On Aug 14, 5:01 pm, Dave Angel da...@ieee.org wrote:
 
 Interesting that when you complain about other's grammatical typos,
 you're so careless with your own.
 
 know - now
 i - I
 accustom - accustomed
 the this - this
 
 I'm inclined to ignore typos in emails except in the case where the
 intent is to abuse others.
 
 My intent is NOT to abuse, but to enlighten. And you need to look up
 the definition of typo because i am not complaining about typos. Typos
 are accidents. Even the best of us suffer from accidents.
 
 What i AM complaining about is the adoption of a collectively foolish
 consistency. Used to and supposed to is the verbiage of children
 and idiots. I am trying to break these people out of such foolish
 loops. You should be thanking me instead of trolling my posts.
 -- 
 http://mail.python.org/mailman/listinfo/python-list
-- 
http://mail.python.org/mailman/listinfo/python-list

[issue12107] TCP listening sockets created without FD_CLOEXEC flag

[Christophe Devriese]

Christophe Devriese christophe.devri...@gmail.com added the comment:

It would already be a nice piece of progress if you could request the
SO_CLOEXEC (with fallback to FD_CLOEXEC), say, in the constructor, or even
with a module variable. I hope at least this change can make it in, so that
we have a decent in-python solution that can be used from within, say,
django.

Christophe

On Sat, May 21, 2011 at 1:24 AM, Antoine Pitrou rep...@bugs.python.orgwrote:


 Changes by Antoine Pitrou pit...@free.fr:


 Removed file: http://bugs.python.org/file22038/unnamed

 ___
 Python tracker rep...@bugs.python.org
 http://bugs.python.org/issue12107
 ___


--
Added file: http://bugs.python.org/file22050/unnamed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12107
___It would already be a nice piece of progress if you could request the 
SO_CLOEXEC (with fallback to FD_CLOEXEC), say, in the constructor, or even with 
a module variable. I hope at least this change can make it in, so that we have 
a decent in-python solution that can be used from within, say, django.div

br/divdivChristophe/divdivbrdiv class=gmail_quoteOn Sat, May 
21, 2011 at 1:24 AM, Antoine Pitrou span dir=ltrlt;a 
href=mailto:rep...@bugs.python.org;rep...@bugs.python.org/agt;/span 
wrote:br

blockquote class=gmail_quote style=margin:0 0 0 .8ex;border-left:1px #ccc 
solid;padding-left:1ex;div class=imbr
Changes by Antoine Pitrou lt;a 
href=mailto:pit...@free.fr;pit...@free.fr/agt;:br
br
br
/divRemoved file: a href=http://bugs.python.org/file22038/unnamed; 
target=_blankhttp://bugs.python.org/file22038/unnamed/abr
divdiv/divdiv class=h5br
___br
Python tracker lt;a 
href=mailto:rep...@bugs.python.org;rep...@bugs.python.org/agt;br
lt;a href=http://bugs.python.org/issue12107; 
target=_blankhttp://bugs.python.org/issue12107/agt;br
___br
/div/div/blockquote/divbr/div
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12107] TCP listening sockets created without FD_CLOEXEC flag

[Christophe Devriese]

Christophe Devriese christophe.devri...@gmail.com added the comment:

I realize this bugreport cannot fix 35 years of a bad design decision in
linux. That's not the intention (that's a gordian knot I *will* be keeping a
safe distance from). The intention is to create a saner default situation
for most python programs.

Christophe

2011/5/20 Charles-François Natali rep...@bugs.python.org


 Charles-François Natali neolo...@free.fr added the comment:

 Hello Christophe,

 First and foremost, I think that the FD_CLOEXEC approach is terminally
 broken, as it should have been the default in Unix. Now, we're stuck with
 this bad design.
 But we can't simply change the default to FD_CLOEXEC, for two reasons:
 - we can't silently change the Unix semantics
 - this is going to break some applications: for example, FD inherited
 across exec is used by super servers such as inetd, and there are others
 very legitimate uses

   in the class TCPServer
   add the following 2 lines in __init__ after self.socket = socket( ...:
 flags = fcntl.fcntl(self.socket, fcntl.F_GETFD)
 fcntl.fcntl(self.socket, fcntl.F_SETFD, flags | fcntl.FD_CLOEXEC)

 There are at least two problems with this approach:
 1) there's a race between the socket creation and the call to fcntl
 2) accept doesn't necessarily inherit the FD_CLOEXEC flag

 1) can be fixed on systems that support it through SOCK_CLOEXEC
 2) can be fixed on systems that support it through accept4(), but it seems
 to break badly on some systems, see issue #10115

 But I think this is a perfectly legitimate request, so one approach to
 tackle this problem could be:
 - since accept4() seems to fail so badly in some configurations, the only
 portable and reliable choice left is probably to call accept() then
 fcntl(FD_CLOEXEC) (there's a race, but it's better than nothing). We might
 reconsider this syscall in a couple years when we're sure it's implemented
 correctly
 - in the socketserver module, add a new set_socket_cloexec attribute to
 BaseServer, which would do the right thing (i.e. create the socket with
 SOCK_CLOEXEC if available, otherwise call fcntl(FD_CLOEXEC)), and in
 TCPServer, call fcntl(FD_CLOEXEC) after accept.

 That way, this would at least fix the problem for people using the
 socketserver module. People using sockets directly of course have the option
 of using SOCK_CLOEXEC and fcntl(FD_CLOEXEC) explicitely in their code.

 Gregory, any thoughts on this?

 --

 ___
 Python tracker rep...@bugs.python.org
 http://bugs.python.org/issue12107
 ___


--
Added file: http://bugs.python.org/file22038/unnamed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12107
___I realize this bugreport cannot fix 35 years of a bad design decision in linux. 
That#39;s not the intention (that#39;s a gordian knot I *will* be keeping a 
safe distance from). The intention is to create a saner default situation for 
most python programs.div

br/divdivChristophebrbrdiv class=gmail_quote2011/5/20 
Charles-François Natali span dir=ltrlt;a 
href=mailto:rep...@bugs.python.org;rep...@bugs.python.org/agt;/spanbrblockquote
 class=gmail_quote style=margin:0 0 0 .8ex;border-left:1px #ccc 
solid;padding-left:1ex;

br
Charles-François Natali lt;a 
href=mailto:neolo...@free.fr;neolo...@free.fr/agt; added the comment:br
br
Hello Christophe,br
br
First and foremost, I think that the FD_CLOEXEC approach is terminally broken, 
as it should have been the default in Unix. Now, we#39;re stuck with this bad 
design.br
But we can#39;t simply change the default to FD_CLOEXEC, for two reasons:br
- we can#39;t silently change the Unix semanticsbr
- this is going to break some applications: for example, FD inherited across 
exec is used by super servers such as inetd, and there are others very 
legitimate usesbr
div class=imbr
gt;  in the class TCPServerbr
gt;  add the following 2 lines in __init__ after self.socket = socket( 
...:br
gt;    flags = fcntl.fcntl(self.socket, fcntl.F_GETFD)br
gt;    fcntl.fcntl(self.socket, fcntl.F_SETFD, flags | fcntl.FD_CLOEXEC)br
br
/divThere are at least two problems with this approach:br
1) there#39;s a race between the socket creation and the call to fcntlbr
2) accept doesn#39;t necessarily inherit the FD_CLOEXEC flagbr
br
1) can be fixed on systems that support it through SOCK_CLOEXECbr
2) can be fixed on systems that support it through accept4(), but it seems to 
break badly on some systems, see issue #10115br
br
But I think this is a perfectly legitimate request, so one approach to tackle 
this problem could be:br
- since accept4() seems to fail so badly in some configurations, the only 
portable and reliable choice left is probably to call accept() then 
fcntl(FD_CLOEXEC) (there#39;s a race, but it#39;s better than nothing). We 
might reconsider this syscall in a couple

[issue12107] TCP listening sockets created without FD_CLOEXEC flag

[Christophe Devriese]

New submission from Christophe Devriese christophe.devri...@gmail.com:

The specific issue this is creating is that a malicious user could use this 
socket in a subprocess which is started from a library (ie. I'm using a .so, 
which calls fork/exec).

A second failure mode is starting a daemon from withing, say, a django 
application. Djano opens a TCP listening socket, then starts up a daemon to 
provide some sort of service in the background. The daemon keeps running and 
inherits the socket. Now you restart the django app.

It refuses to start ! Why ? Because the socket was inherited, the listening 
socket isn't actually closed, and this results in the socket being stuck in 
CLOSE_WAIT as long as the daemon is running.

It seems to me that it is almost never the case that you'd want a TCP listening 
socket to be preserved across exec, and not setting this flag should thus be 
considered a bug for 2 reasons :

1) it results in accidental disclosure of information that shouldn't be exposed 
in certain cases.
2) it can result in denial of service

Solution : 

update SocketServer.py :
  in the class TCPServer
  add the following 2 lines in __init__ after self.socket = socket( ...:
flags = fcntl.fcntl(self.socket, fcntl.F_GETFD)
fcntl.fcntl(self.socket, fcntl.F_SETFD, flags | fcntl.FD_CLOEXEC)

--
messages: 136273
nosy: Christophe.Devriese
priority: normal
severity: normal
status: open
title: TCP listening sockets created without FD_CLOEXEC flag
type: security

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12107
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10949] logging.RotatingFileHandler not robust enough

[Christophe Kalt]

New submission from Christophe Kalt k...@taranis.org:

logging.RotatingFileHandler.doRollover() can fail leaving the handler with a 
closed filehandle, causing all subsequent logging attempts to fail:

 import logging
 import logging.handlers
 logging.getLogger().addHandler(logging.handlers.RotatingFileHandler('testlog',
  None, 10, 5))
 logging.getLogger().setLevel(logging.INFO)
 logging.info('qwertyuiop')
 os.system('ls -l testlog*')
-rw-r--r-- 1 - - 11 Jan 19 10:02 testlog
-rw-r--r-- 1 - -  0 Jan 19 10:02 testlog.1
0
 os.remove('testlog')
 logging.info('qwertyuiop')
Traceback (most recent call last):
  File /home8/taraniso/opt/lib/python2.6/logging/handlers.py, line 72, in emit
self.doRollover()
  File /home8/taraniso/opt/lib/python2.6/logging/handlers.py, line 129, in 
doRollover
os.rename(self.baseFilename, dfn)
OSError: [Errno 2] No such file or directory
 logging.info('qwertyuiop')
Traceback (most recent call last):
  File /home8/taraniso/opt/lib/python2.6/logging/handlers.py, line 71, in emit
if self.shouldRollover(record):
  File /home8/taraniso/opt/lib/python2.6/logging/handlers.py, line 145, in 
shouldRollover
self.stream.seek(0, 2)  #due to non-posix-compliant Windows feature
ValueError: I/O operation on closed file
 logging.info('qwertyuiop')
Traceback (most recent call last):
  File /home8/taraniso/opt/lib/python2.6/logging/handlers.py, line 71, in emit
if self.shouldRollover(record):
  File /home8/taraniso/opt/lib/python2.6/logging/handlers.py, line 145, in 
shouldRollover
self.stream.seek(0, 2)  #due to non-posix-compliant Windows feature
ValueError: I/O operation on closed file

Fix seems trivial enough, attaching.  This is against 2.6.5, browsing 
subversion online seems to indicate it is needed on the trunk as well, although 
it won't apply cleanly.

--
components: Library (Lib)
files: logging.diff
keywords: patch
messages: 126541
nosy: kalt
priority: normal
severity: normal
status: open
title: logging.RotatingFileHandler not robust enough
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file20454/logging.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10949
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

ANNOUNCE: TGWebServices 1.2.4

[Christophe de Vienne]

Hi,

I am pleased to announce the release of TGWebServices 1.2.4.

 Download: http://pypi.python.org/pypi/TGWebServices/1.2.4
 Homepage: http://code.google.com/p/tgws/

What is it?
===

TGWebServices provides a very easy way to implement multi-procotol
webservices in your TurboGears application.

What's New?
===

This release brings a few improvements and bug fixes.

Among them :
 - native date, time and datetime support
 - base64-encodede binary support
 - Improved documentation

A more complete Changelog is available at
http://wiki.tgws.googlecode.com/hg/changelog.html


Cheers,

Christophe
-- 
http://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

[issue8893] file.{read,readlines} behaviour on Solaris

[Christophe Kalt]

Christophe Kalt k...@taranis.org added the comment:

I haven't had a chance to build Python to check, but from the test output I
suspect the problem to be different on FreeBSD.

--
Added file: http://bugs.python.org/file17750/unnamed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8893
___I haven#39;t had a chance to build Python to check, but from the test output I 
suspect the problem to be different on FreeBSD.br
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8893] file.{read,readlines} behaviour on Solaris

[Christophe Kalt]

Christophe Kalt pyt...@ote.taranis.org added the comment:

This is on Solaris 10, but I also see it on Solaris 8 w/ Python 2.4.
Just tried Python 3.6.1, and it doesn't seem to have that problem.
Python 2.7b2 has the problem.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8893
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8893] file.{read,readlines} behaviour on Solaris

[Christophe Kalt]

Christophe Kalt pyt...@ote.taranis.org added the comment:

Antoine:

I'm not sure what the expected behaviour should be either, this is certainly 
for others more familiar with Python than I to decide.  Although I am certainly 
annoyed that the current behaviour differs between Solaris and Linux.  Haven't 
had time to check other platforms to see how things should be.

Also, the behaviour seems inconsistent between the various file methods on 
Solaris which seems wrong.  Finally, from looking into fileobject.c, clearerr() 
is used in most places and the omissions (corrected by my patch) do seem 
unintentional to me, e.g. bugs.

Hope this helps.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8893
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8893] file.{read,readlines} behaviour on Solaris

[Christophe Kalt]

Christophe Kalt k...@taranis.org added the comment:

FreeBSD is yet another beast:

$ uname -rs
FreeBSD 8.0-STABLE
$ python -V
Python 2.5.5
$ python readlines.py
read :  []
readlines:  []
readline :

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8893
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8893] file.{read,readlines} behaviour on Solaris

[Christophe Kalt]

New submission from Christophe Kalt pyt...@ote.taranis.org:

The following snippet of code is a concise way to exhibit the problem:

import os

wr = open('/tmp/test', 'w')
wr.write('oink\noink\n')
rd = open('/tmp/test', 'r')
rdlns = open('/tmp/test', 'r')
# first, read til EOF is reached (which is right away)
assert len(rd.read()) == 0
assert len(rdlns.readlines()) == 0
# add data to the file
wr.flush()
# try to read again
print 'read : ', rd.read().split() # fails
print 'readlines: ', rdlns.readlines() # fails
print 'readline : ', rdlns.readline().strip() # succeeds
# cleanup
wr.close()
rd.close()
rdlns.close()
os.remove('/tmp/test')


On Linux, here is the output:
$ python2.6 src/readlines.py
read :  ['oink', 'oink']
readlines:  ['oink\n', 'oink\n']
readline :  

On Solaris, here is the output:
$ python src/readlines.py
read :  []
readlines:  []
readline :  oink

The problems comes from the fact that once EOF is reached, nothing more will be 
read from the file on subsequent reads, as noted in the manual page 
(http://docs.sun.com/app/docs/doc/816-5168/getchar-3c?a=view):

If the stream is at end-of-file, the end-of-file indicator for the stream is 
set and these functions return EOF. For standard-conforming (see standards(5)) 
applications, if the end-of-file indicator for the stream is set, these 
functions return EOF whether or not the stream is at end-of-file.

The attached diff fixes the problem.

--
assignee: theller
components: ctypes
files: fileobject.diff
keywords: patch
messages: 106999
nosy: kalt, theller
priority: normal
severity: normal
status: open
title: file.{read,readlines} behaviour on Solaris
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file17542/fileobject.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8893
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6715] xz compressor support

[Christophe Simonis]

Changes by Christophe Simonis simonis.christo...@gmail.com:


--
nosy: +Christophe Simonis

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6715
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue444582] Finding programs in PATH, addition to os

[Christophe Simonis]

Changes by Christophe Simonis simonis.christo...@gmail.com:


--
nosy: +Christophe Simonis

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue444582
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8740] infinite recursion with setfilesystemencoding and pdb

[Christophe Combelles]

Christophe Combelles cc...@free.fr added the comment:

(I forgot to mention that the bug occured on python 3.1.2.)

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8740
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8740] infinite recursion with setfilesystemencoding and pdb

[Christophe Combelles]

New submission from Christophe Combelles cc...@free.fr:

This leads to a maximum recursion depth error:

$ python3.1
 import sys, pdb
 sys.setfilesystemencoding('iso8859-7')
 pdb.set_trace()

I'm on ubuntu 10.04 x86_64, with LANG=fr_FR.utf8

--
components: None
messages: 105904
nosy: ccomb
priority: normal
severity: normal
status: open
title: infinite recursion with setfilesystemencoding and pdb
type: behavior
versions: Python 3.1

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8740
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8740] infinite recursion with setfilesystemencoding and pdb

[Christophe Combelles]

Christophe Combelles cc...@free.fr added the comment:

Traceback (most recent call last):
  File /usr/lib/python3.1/encodings/__init__.py, line 98, in search_function
level=0)
  File /usr/lib/python3.1/encodings/__init__.py, line 98, in search_function
level=0)
(...)
  File /usr/lib/python3.1/encodings/__init__.py, line 98, in search_function
level=0)
  File /usr/lib/python3.1/encodings/__init__.py, line 98, in search_function
level=0)
  File /usr/lib/python3.1/encodings/__init__.py, line 83, in search_function
norm_encoding = normalize_encoding(encoding)
  File /usr/lib/python3.1/encodings/__init__.py, line 55, in 
normalize_encoding
if isinstance(encoding, bytes):
RuntimeError: maximum recursion depth exceeded while calling a Python object

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8740
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7978] SocketServer doesn't handle syscall interruption

[Christophe Simonis]

Changes by Christophe Simonis simonis.christo...@gmail.com:


--
nosy: +Christophe Simonis

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7978
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4331] Can't use _functools.partial() created function as method

[Christophe Simonis]

Christophe Simonis simonis.christo...@gmail.com added the comment:

I followed the advice of Raymond and implement a descriptor on partial.

--
keywords: +patch
Added file: http://bugs.python.org/file15800/issue4331.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4331
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4652] IDLE does not work with Unicode

[Jean-Christophe Helary]

Jean-Christophe Helary jean.christophe.hel...@gmail.com added the comment:

I've installed Python 3.1.1 on OSX today.
1) When I use the Japanese input from OSX, IDLE interprets any character 
I attempt to type as a space.
2) When I paste a Japanese string from a different place, it is 
correctly handled. For ex:
 print('ここ')
ここ
 

While on Python 2.5's IDLE I had:
 print('ここ')
Unsupported characters in input

 

by default.

In any case, IDLE 3.1.1 does not respect the input source and that makes 
it impossible to directly type Japanese (if not other double byte 
character based languages).

Note: IDLE respect OSX dead keys and I can correctly use Alt+c to 
input ç.

--
nosy: +jchelary
versions: +Python 3.1 -Python 3.0

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4652
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4331] Can't use _functools.partial() created function as method

[Christophe Simonis]

Changes by Christophe Simonis simonis.christo...@gmail.com:


--
nosy: +Christophe Simonis

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4331
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

how to find out the version of a certain installed package

[Christophe]

Hi,

In a projecet I'm making using pycrypto, I need to find out the
current installed version of pycrypto. After looking around, I found
out that pkg_resources.requires(pycrypto) will give me a string
containing the version number, but is this the only way to do it or
are there other ways?

thanks,

Christophe
--
http://mail.python.org/mailman/listinfo/python-list

Re: how to find out the version of a certain installed package

[Christophe]

great! thanks for you fast response.

Christophe

On Tue, Sep 30, 2008 at 6:30 PM, M.-A. Lemburg [EMAIL PROTECTED] wrote:

 On 2008-09-30 18:17, Christophe wrote:
  Hi,
 
  In a projecet I'm making using pycrypto, I need to find out the
  current installed version of pycrypto. After looking around, I found
  out that pkg_resources.requires(pycrypto) will give me a string
  containing the version number, but is this the only way to do it or
  are there other ways?

 Most packages have a .__version__ attribute in their top-level
 package dir which you can query.

 You do have to import the base package, though, in order to find
 out.

 Thanks,
 --
 Marc-Andre Lemburg
 eGenix.com

 Professional Python Services directly from the Source  (#1, Sep 30 2008)
  Python/Zope Consulting and Support ...http://www.egenix.com/
  mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
  mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
 

  Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611

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

[issue3041] autodoc does not support unicode docstrings

[Christophe de Vienne]

New submission from Christophe de Vienne [EMAIL PROTECTED]:

If I define unicode docstrings in my python source, autodoc crash
because it tries to decode them, which force a ascii encode first.

A trivial patch fix the issue :

Index: sphinx/ext/autodoc.py
===
--- sphinx/ext/autodoc.py   (révision 63954)
+++ sphinx/ext/autodoc.py   (copie de travail)
@@ -218,7 +218,7 @@
 module = getattr(todoc, '__module__', None)
 if module is not None:
 charset = get_module_charset(module)
-docstrings = [docstring.decode(charset) for docstring in
docstrings]
+docstrings = [docstring.decode(charset) for docstring in
docstrings if not isinstance(docstring, unicode)]
 
 # add docstring content
 for docstring in docstrings:

--
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 67710
nosy: cdevienne, georg.brandl
severity: normal
status: open
title: autodoc does not support unicode docstrings
type: crash

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3041
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1734346] patch for bug 1170311 zipfile UnicodeDecodeError

[Christophe Kalt]

Christophe Kalt [EMAIL PROTECTED] added the comment:

Any chance of this making it in sometime?
The current behaviour is rather limiting/annoying.

--
nosy: +kalt

_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1734346
_
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

PyCon FR - Journées Python

[Christophe Combelles]

PyCon FR will take place in Paris, France, 17-18 May 2008.
The French Python Association (AFPY) is organizing this event called Journées
Python for the second time.

We expect most talks to be in french, but any proposal in english is also 
greatly welcome! You may submit your idea of talks and presentations now,
either here if you speak french: 
http://fr.pycon.org/actualites/appel-a-propositions/ ,
or here if you don't : pycon -at- afpy.org

Topics:

We're expecting talks about anything related to the Python programming
language, including:

 * the language and its libraries
 * the web technologies
 * Python in scientific computing
 * game programming
 * development environnement setup
 * agile programmnig and tests

The expected audience will span on any level, from the beginner to the
expert. Thus, your talk may fit even to beginners and will be welcome.

Other formats:

As well as regular talks, we will host tutorials about Python
programming for beginners, and we may include 15-minutes lightning
talks on any topic you want to talk about (e.g.: a project you're
working on).

You may submit debate topics for open discussions too.

Important dates:

 * March, 7th : Call for papers
 * March, 30th : Paper submissions are closed
 * April 4th : Final schedule publication

How to get involved?

If you want to attend as a simple visitor, please register on this
page to help us count the expected audience:

 * http://fr.pycon.org/inscription

To submit a talk, tutorial, etc., please register with the link above,
and fill the following form:

 * http://fr.pycon.org/contact/proposition-de-presentation

For any information about the event, go to:

 * http://fr.pycon.org

get in touch with the organization team via: pycon -at- afpy.org

See you soon!

--'AFPy Team.

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

PyCon FR - Journées Python

[Christophe Combelles]

PyCon FR will take place in Paris, France, 17-18 May 2008.
The French Python Association (AFPY) is organizing this event called Journées
Python for the second time.

We expect most talks to be in french, but any proposal in english is also 
greatly welcome! You may submit your idea of talks and presentations now,
either here if you speak french: 
http://fr.pycon.org/actualites/appel-a-propositions/ ,
or here if you don't : pycon -at- afpy.org

Topics:

We're expecting talks about anything related to the Python programming
language, including:

 * the language and its libraries
 * the web technologies
 * Python in scientific computing
 * game programming
 * development environnement setup
 * agile programmnig and tests

The expected audience will span on any level, from the beginner to the
expert. Thus, your talk may fit even to beginners and will be welcome.

Other formats:

As well as regular talks, we will host tutorials about Python
programming for beginners, and we may include 15-minutes lightning
talks on any topic you want to talk about (e.g.: a project you're
working on).

You may submit debate topics for open discussions too.

Important dates:

 * March, 7th : Call for papers
 * March, 30th : Paper submissions are closed
 * April 4th : Final schedule publication

How to get involved?

If you want to attend as a simple visitor, please register on this
page to help us count the expected audience:

 * http://fr.pycon.org/inscription

To submit a talk, tutorial, etc., please register with the link above,
and fill the following form:

 * http://fr.pycon.org/contact/proposition-de-presentation

For any information about the event, go to:

 * http://fr.pycon.org

get in touch with the organization team via: pycon -at- afpy.org

See you soon!

--'AFPy Team.
-- 
http://mail.python.org/mailman/listinfo/python-list

[issue1757062] Pickle fails on BeautifulSoup's navigableString instances

[Christophe Michel]

Christophe Michel added the comment:

I started by isolating the most minimalist code that triggers the error.
If you play a bit with NavigableString, you will end up with the
attached code.

As expected, this program fails with RuntimeError: maximum recursion
depth exceeded
The evil recursion proceeds as follows :

  File C:\Python25\lib\pickle.py, line 1364, in dump
Pickler(file, protocol).dump(obj)

Initial call to dump(), as intended.

  File C:\Python25\lib\pickle.py, line 224, in dump
self.save(obj)

save() calls obj.__reduce_ex(), obj being our EvilString instance.

This function is defined in copyreg.py, line 58 and following my
example, returns a tuple containing three elements:
1) the _reconstructor function, as defined in copyreg.py, line 46
2) a tuple : (class '__main__.EvilString', type 'unicode',
'__main__.EvilString' instance at 0x)
   First element is the actual class of obj, second is the base class,
and third is the current instance (known as state).
3) an empty dict {}

  File C:\Python25\lib\pickle.py, line 331, in save
self.save_reduce(obj=obj, *rv)

save_reduce() calls self.save() twice:
- first on the func argument, which is the _reconstructor function. This
call works as intended
- next on the tuple (class '__main__.EvilString', type 'unicode',
'__main__.EvilString' instance at 0x)

  File C:\Python25\lib\pickle.py, line 403, in save_reduce
save(args)
  File C:\Python25\lib\pickle.py, line 286, in save
f(self, obj) # Call unbound method with explicit self

save() finds out its argument is a Tuple, and calls save_tuple()
appropriately

  File C:\Python25\lib\pickle.py, line 564, in save_tuple
save(element)

... and save_tuple() calls save() on each element of the tuple.
See what's wrong ?
This means calling save() again on the EvilString instance. Which, in
turn, will call save_reduce() on it, and so on.

The problem lies in _reduce_ex(), in the definition of the state of the
object:

copyreg.py, lines 65 to 70:
if base is object:
state = None
else:
if base is self.__class__:
raise TypeError, can't pickle %s objects % base.__name__
state = base(self)

When this code gets executed on an EvilString instance, base is the type
'unicode'.
Since it's not an object, and since it's not the actual class EvilString
either, the following line gets executed:
state=base(self)

Which corresponds to unicode(self), or self.__unicode__, which returns
an EvilString instance, not a variable of type unicode.
And there starts the recursion.

I don't know if this is flaw in the design of _reduce_ex, or a flaw
inherent to having __unicode__(self) returning self.
My guess is the latter is right.

--
nosy: +altherac

_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1757062
_

bug-175062.py
Description: Binary data
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Is PEP-8 a Code or More of a Guideline?

[Christophe]

Joe Riopel a écrit :
 Each requires exactly the same number of key strokes when I do the
 math. (Too lazy to explain further...)
 
 foo_bar
 f, o, o, shift + underscore, b, a, r = 8
 fooBar
 f, o, o, shift + b, a, r = 7

f, o, o, _, b, a, r = 7
f, o, o, shift + b, a, r = 8

Also the shift+b is much more work than 2 keypresses IMHO. On the other 
hand, the underscore is done by pressing the 8 key without any other 
modifier which is very easy and accessible. Yeap, french layout rules 
for that naming convention :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Christophe Cavalaria]

Istvan Albert wrote:

 On May 19, 3:33 am, Martin v. Löwis [EMAIL PROTECTED] wrote:
 
 That would be invalid syntax since the third line is an assignment
  with target identifiers separated only by spaces.

 Plus, the identifier starts with a number (even though ６ is not DIGIT
 SIX, but FULLWIDTH DIGIT SIX, it's still of category Nd, and can't
 start an identifier).
 
 Actually both of these issues point to the real problem with this PEP.
 
 I knew about them (note that the colon is also missing) alas I
 couldn't fix them.
 My editor would could not remove a space or add a colon anymore, it
 would immediately change the rest of the characters to something
 crazy.
 
 (Of course now someone might feel compelled to state that this is an
 editor problem but I digress, the reality is that features need to
 adapt to reality, moreso had I used a different editor I'd be still
 unable to write these characters).

The reality is that the few users who care about having chinese in their
code *will* be using an editor that supports them.

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Christophe]

[EMAIL PROTECTED] a écrit :
 Steven D'Aprano wrote:
 I would find it useful to be able to use non-ASCII characters for heavily
 mathematical programs. There would be a closer correspondence between the
 code and the mathematical equations if one could write D(u*p) instead of
 delta(mu*pi).
 
 Just as one risk here:
 When reading the above on Google groups, it showed up as if one could
 write ?(u*p)...
 When quoting it for response, it showed up as could write D(u*p).
 
 I'm sure that the symbol you used was neither a capital letter d nor a
 question mark.
 
 Using identifiers that are so prone to corruption when posting in a
 rather popular forum seems dangerous to me--and I'd guess that a lot
 of source code highlighters, email lists, etc have similar problems.
 I'd even be surprised if some programming tools didn't have similar
 problems.

So, it was google groups that continuously corrupted the good UTF-8 
posts by force converting them to ISO-8859-1?

Of course, there's also the possibility that it is a problem on *your* 
side so, to be fair I've launched google groups and looked for this 
thread. And of course the result was that Steven's post displayed 
perfectly. I didn't try to reply to it of course, no need to clutter 
that thread anymore than it is.

-- 
Δ(µ*π)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Christophe]

[EMAIL PROTECTED] a écrit :
 Christophe wrote:
 [EMAIL PROTECTED] a ecrit :
 Steven D'Aprano wrote:
 I would find it useful to be able to use non-ASCII characters for heavily
 mathematical programs. There would be a closer correspondence between the
 code and the mathematical equations if one could write D(u*p) instead of
 delta(mu*pi).
 Just as one risk here:
 When reading the above on Google groups, it showed up as if one could
 write ?(u*p)...
 When quoting it for response, it showed up as could write D(u*p).

 I'm sure that the symbol you used was neither a capital letter d nor a
 question mark.

 Using identifiers that are so prone to corruption when posting in a
 rather popular forum seems dangerous to me--and I'd guess that a lot
 of source code highlighters, email lists, etc have similar problems.
 I'd even be surprised if some programming tools didn't have similar
 problems.
 So, it was google groups that continuously corrupted the good UTF-8
 posts by force converting them to ISO-8859-1?

 Of course, there's also the possibility that it is a problem on *your*
 side
 
 Well, that's part of the point isn't it?  It seems incredibly naive to
 me to think that you could use whatever symbol was intended and have
 it show up, and the well fix your machine! argument doesn't fly.  A
 lot of the time programmers have to look at stack traces on end-user's
 machines (whatever they may be) to help debug.  They have to look at
 code on the (GUI-less) production servers over a terminal link.  They
 have to use all kinds of environments where they can't install the
 latest and greatest fonts.  Promoting code that becomes very hard to
 read and debug in real situations seems like a sound negative to me.

Who displays stack frames? Your code. Whose code includes unicode 
identifiers? Your code. Whose fault is it to create a stack trace 
display procedure that cannot handle unicode? You. Even if you don't 
make use of them, you still have to fix the stack trace display 
procedure because the exception error message can include unicode text 
*today*

You should know that displaying and editing UTF-8 text as if it was 
latin-1 works very very well.

Also, Terminals have support for UTF-8 encodings already. Or you could 
always use kate+fish to edit your script on the distant server without 
such problems (fish is a KDE protocol used to access a computer with ssh 
as if it was a hard disk and kate is the standard text/code editor) It's 
a matter of tools.
-- 
http://mail.python.org/mailman/listinfo/python-list