On Mon, Mar 18, 2019 at 9:34 AM Steven D'Aprano wrote:
>
> On Mon, Mar 18, 2019 at 01:13:29AM +1100, Chris Angelico wrote:
> [...]
> > Yes, it will. Can you determine whether some code does this? Can you
> > recognize what kind of object is on the left of a percent sign?
> > Remember, it quite pos
On Mon, Mar 18, 2019 at 01:13:29AM +1100, Chris Angelico wrote:
[...]
> Yes, it will. Can you determine whether some code does this? Can you
> recognize what kind of object is on the left of a percent sign?
> Remember, it quite possibly won't be a literal.
I don't understand whether your question
francismb writes:
> On 3/15/19 4:54 AM, Stephen J. Turnbull wrote:
> > What 2to3 does is to handle a lot of automatic conversions, such as
> > flipping the identifiers from str to bytes and unicode to str. It was
> > necessary to have some such tool because of the very large amount of
> > suc
On 3/15/19 11:09 PM, Chris Angelico wrote:
> And, are you going to run this function on every single code snippet
> before you try it?
If just trying, may be not. But yes, if I care to know where the
applicability limits are (interpreter versions) before integrating it.
IMHO I don't think it's a g
On Mon, Mar 18, 2019 at 1:09 AM francismb wrote:
>
> On 3/15/19 11:09 PM, Chris Angelico wrote:
> > Python 3.5 introduced the modulo operator for bytes objects. How are
> > you going to write a function that determines whether or not a piece
> > of code depends on this?
> I'm not sure I understand
On 3/15/19 11:09 PM, Chris Angelico wrote:
> Python 3.5 introduced the modulo operator for bytes objects. How are
> you going to write a function that determines whether or not a piece
> of code depends on this?
I'm not sure I understand the question. Isn't *a piece of code* that
does a modulo oper
On Sat, Mar 16, 2019 at 12:28 PM Steven D'Aprano wrote:
>
> On Fri, Mar 15, 2019 at 08:10:58PM +0100, francismb wrote:
> > On 3/15/19 4:54 AM, Stephen J. Turnbull wrote:
> > > Not really. For example, addition of syntax like "async" and "yield"
> > > fundamentally changes the meaning of "def", in
On Fri, Mar 15, 2019 at 08:10:58PM +0100, francismb wrote:
> On 3/15/19 4:54 AM, Stephen J. Turnbull wrote:
> > Not really. For example, addition of syntax like "async" and "yield"
> > fundamentally changes the meaning of "def", in ways that *could not*
> > be fully emulated in earlier Pythons. T
On Sat, Mar 16, 2019 at 7:35 AM francismb wrote:
>
> Thanks!
> On 3/15/19 8:56 PM, Chris Angelico wrote:
> > The same is true of books that discuss the language, blog posts giving
> > tips and tricks, Stack Overflow answers, and everything else that
> > incorporates code that people might want to
Thanks!
On 3/15/19 8:56 PM, Chris Angelico wrote:
> The same is true of books that discuss the language, blog posts giving
> tips and tricks, Stack Overflow answers, and everything else that
> incorporates code that people might want to copy and paste. What
> version of Python do you need? What's t
On Sat, Mar 16, 2019 at 5:43 AM francismb wrote:
>
> On 3/14/19 9:47 PM, Chris Angelico wrote:
> > What happens when someone wants to support multiple Python versions?
> > "Requires Python 3.5 or newer" is easy. Forcing people to install the
> > correct one for each version isn't.
> What are the r
On 3/15/19 2:34 PM, francismb wrote:
I understand that no one really wants to annoy the language users by
breaking the code and that's why those changes are considered carefully.
Is that may be because there is no easy way to write a translator? or
there is no translator to help transition?
T
On 3/15/19 4:54 AM, Stephen J. Turnbull wrote:
> The thing about "within 3" upgrades is that that kind of project-wide
> annoyance is going to be minimal, because the language is mostly
> growing in power, not changing the semantics of existing syntax. Such
> changes are very rare, and considere
On 3/15/19 4:54 AM, Stephen J. Turnbull wrote:
> What 2to3 does is to handle a lot of automatic conversions, such as
> flipping the identifiers from str to bytes and unicode to str. It was
> necessary to have some such tool because of the very large amount of
> such menial work needed to change a
On 3/15/19 4:54 AM, Stephen J. Turnbull wrote:
> Not really. For example, addition of syntax like "async" and "yield"
> fundamentally changes the meaning of "def", in ways that *could not*
> be fully emulated in earlier Pythons. The semantics simply were
> impossible to produce -- that's why synt
Le 15 mars 2019 à 19:44:15, francismb
([email protected](mailto:[email protected])) a écrit:
>
>
> On 3/14/19 9:47 PM, Chris Angelico wrote:
> > What happens when someone wants to support multiple Python versions?
> > "Requires Python 3.5 or newer" is easy. Forcing people to install the
> > corr
Hi Greg,
On 3/15/19 5:33 AM, Greg Ewing wrote:
> Not really. Having to translate all your source every time a
> minor version update occurs would be a huge hassle.
PythonUAAS: upload the sources (zipped or packaged) and get them updated
back ;-)
Regards,
--francis
On 3/14/19 9:47 PM, Chris Angelico wrote:
> What happens when someone wants to support multiple Python versions?
> "Requires Python 3.5 or newer" is easy. Forcing people to install the
> correct one for each version isn't.
What are the reasons why people want to support multiple Python
versions,
francismb wrote:
Yes a source transformer, but to be applied to some 3.x version to move
it to the next 3.x+1, and so on ... (instead of '2to3' a kind of
'nowtonext', aka 'python_next')
Couldn't that relax the tension on doing 'backward compatibility
changes' a bit ?
Not really. Having to tran
francismb writes:
> Trying to keep a single code base for 2/3 seems like a good idea
> (may be the developer just cannot change to 3 fast due how big the
> step was) but that also have the limitation on how far you can go
> using new features.
This doesn't work very well: you can't use 3 at a
On Thu, Mar 14, 2019 at 09:33:21PM +0100, francismb wrote:
[...]
> > Do you mean something like 2to3? Something which transforms source code
> > written in Python?
> >
> Yes a source transformer, but to be applied to some 3.x version to move
> it to the next 3.x+1, and so on ... (instead of '2to3'
Hi Paul,
On 3/12/19 12:21 AM, Paul Moore wrote:
> That sounds very similar to 2to3, which seemed like a good approach to
> the Python 2 to Python 3 transition, but fell into disuse because
> people who have to support multiple versions of Python in their code
> found it *far* easier to do so with
On Fri, Mar 15, 2019 at 7:39 AM francismb wrote:
>
> Hi Steven,
>
> On 3/12/19 12:25 AM, Steven D'Aprano wrote:
> > I don't know who you expect is using this: the Python core developers
> > responsible for adding new language features and changing the grammar,
> > or Python programmers.
> Python c
Hi Steven,
On 3/12/19 12:25 AM, Steven D'Aprano wrote:
> I don't know who you expect is using this: the Python core developers
> responsible for adding new language features and changing the grammar,
> or Python programmers.
Python core devs should write the 'python_next' and 'is_python_code'
part
On Mon, Mar 11, 2019 at 09:38:21PM +0100, francismb wrote:
> Hi,
> I would like to discuss on the idea of a code (minor) version
> evolver/re-writer (or at least a change indicator). Let's see one wants
> to add a feature on the next version and some small grammar change is
> needed, then the scrip
On Mon, 11 Mar 2019 at 20:39, francismb wrote:
>
> Hi,
> I would like to discuss on the idea of a code (minor) version
> evolver/re-writer (or at least a change indicator). Let's see one wants
> to add a feature on the next version and some small grammar change is
> needed, then the script upgrade
Hi,
I would like to discuss on the idea of a code (minor) version
evolver/re-writer (or at least a change indicator). Let's see one wants
to add a feature on the next version and some small grammar change is
needed, then the script upgrades/evolves first the current code and then
the new version ca
27 matches
Mail list logo
